Get your own assistant's answers auditedAudit yours

Sample audit, AI-reviewed

Sample report: how often a policy assistant's answers go beyond its sources

Our own demo assistant answered 20 real public questions using a snapshot of Node.js release, support, security and licence documents. Each answer was split into claims and checked against that snapshot. Here is the result, row by row.

The rate on this sample of real public questions

20 real Stack Overflow questions, one answer each. An answer fails when at least one of its claims is unsupported by, or contradicts, the documents it answered from.

  • What counts as a failed answer

    The unit is the answer: it fails when at least one claim is unsupported by or contradicts the snapshot. A rate per claim would be a different number.

    • A paraphrase or a strict entailment of a passage is supported.
    • An inference the documents do not state stays "not found", even when it is true in the world.
    • A sentence about what the assistant found in its passages ("I could not find X") is not a claim about Node.js, so it is never in the rate.
    • A restatement of the user's own question or log, and advice that states no checkable fact, are not claims to check.
  • Why the order is the order

    Types are listed in the order a team would fix them: false statements about what is supported or receiving fixes first, then wrong release facts, then wrong policy or process, then any other unsupported addition. The probable stage comes from the five passages each answer was given, which the assistant logs for every answer.

  • Why the planted arm is separate

    Planting a superseded document in the same index confounded the first run: its passages took retrieval slots from the current schedule, so a failure could look real when the plant caused it. The questions were therefore run twice. The real arm uses current documents only, so no planted text can reach the rate. The planted arm is the first run, kept as recorded, and labels every failure in an answer that retrieved a planted passage as planted.

  • AI-reviewed (not confirmed by a person). The harness proposed every verdict, and in the real arm a separate AI review decided every provisional failure, every claim where the sources disagree, every decline and every answer's verdict, against the full source snapshot.
  • An internal review of our own demo assistant, not a client's system. The Node.js project did not take part in or review it; source tags such as D03#02 refer to our snapshot.
  • Not a benchmark for any assistant or model.
Counts: real questions, current documents only

Source: Our recorded run of 4 November 2026; verdicts decided in an AI review, not confirmed by a person.

Rate

10 of 20 answers failed: 50%, with an exact two-sided 95% interval of 27% to 73%. With 20 answers the interval is wide: this shows the report and the method, not a precise rate for this or any other assistant.

By failure type
Failure type, in fix orderAnswersProbable stage
False support or security commitment0 of 20 (upper bound 14%)None in this sample
Wrong release fact1 of 20 (Q03)Scope and decline rules
Wrong policy or process1 of 20 (Q18)Retrieval
Unsupported addition8 of 20 (Q01, Q04, Q05, Q08, Q09, Q11, Q14, Q15)Generation, scope and decline rules, not assigned

An answer can carry more than one type. A type with no failures gets an exact one-sided upper bound at the same confidence, not a zero.

Failing claims

17 of the 260 claims in the 20 answers. The answer itself flagged 12 of them as not taken from the documentation, and in 6 of the 10 failed answers every failing claim was flagged that way. A flagged claim still counts.

Declines and omissions
CountResult
Declined outright0 of 20
Declined although the sources held the answer0 of 20
Said the documentation has no answer to the core question, though it does2 of 20 (Q13, Q18), counted apart, never in the rate
OmissionsNot measured in this sample
Overturns

The harness flagged 33 provisional failures; 18 were overturned after the AI review and 15 stand. The review also added 2 claims the splitter missed, both failing (Q05, Q14). A further 10 claims, where Node.js's own documents disagree with each other, were left uncounted.

Planted (counted apart)

The same 20 questions, also run with one superseded document planted among the sources (the first run, kept as recorded): 10 answers with planted failures, 22 failing claims. Every one is labelled planted, counted here and never in the rate.

Lead finding: a production rule the assistant never retrieved

Asked whether non-LTS Node.js lines are production-ready, the assistant said the documentation is silent. The Releases page is not.

  • How we know the passage was never seen

    Every answer logs the passages it was given. Ranking is deterministic keyword search (BM25), so the same question always gets the same passages, and ranking the whole snapshot for this question shows where the Releases passage falls.

  • Why "I could not find" is counted apart

    A sentence about what the assistant found is not a claim about Node.js, so it is not in the rate. When it concerns the core question and the sources do hold the answer, it is recorded as a partial decline and counted on its own line. In the real arm, Q13 and Q18 are the two.

  • The Releases page is quoted from the Node.js website, MIT licence, Node.js Website WG contributors.
Report row: Q18

Source: Node.js Releases page, quoted from our snapshot and checked against the live page on 4 November 2026

Question

"What are the differences between Long Term Support (LTS) and Stable versions of Node.js?" The post goes on: "Is there any information on how production ready the "stable" branches are?"

Stack Overflow question 33661274, asked 2015-11-11, CC BY-SA 3.0; usernames removed.

Answer

The key difference is support lifetime, based on the release table [D01#07]:

LineTypeInitial releaseEnd-of-life
4.x (Argon)LTS2015-09-082018-04-30
5.xNon-LTS2015-10-292016-06-30
6.x (Boron)LTS2016-04-262019-04-30
7.xNon-LTS2016-10-252017-06-30
  • LTS lines: These get codenames and move through Active and Maintenance LTS phases, while 5.x and 7.x had neither [D01#07][D10#01]. They also receive backported fixes, which normally spend at least 2 weeks in an Alpha or Current release first [D01#15][D01#16].
  • 8.x and 9.x: 8.x is LTS (Carbon), while 9.x isn't on the codename list [D10#01].

Production readiness: I could not find a statement on this in the Node.js documentation. For long-running production, an LTS line gives you a much longer upgrade runway. Non-LTS lines suit you if you can upgrade within months.

Claims against the sources

27 claims: 24 supported, 1 left uncounted where Node.js documents disagree, 1 not a claim to check (the "could not find" sentence, recorded as a partial decline), and 1 contradicted:

Node.js non-LTS lines suit users who can upgrade within months.

Contradicted by D03#02, the Node.js Releases page: "Production applications should only use Active LTS or Maintenance LTS releases."

Failure type

Wrong policy or process

Probable stage

Retrieval. For this question the Releases passage ranks 7th in the snapshot, and the assistant is given only the top 5, so the answer was written without it. Passages given: D01#15, D08#09, D01#16, D10#01, D01#07.

Fix guidance

Make the passage findable for the way people actually ask: more candidates and a re-ranker, or indexing it under the terms users use. Then have the assistant decline when no retrieved passage states the fact, instead of filling the gap. Frozen question: Q18, the one a before-and-after test would re-run on the fixed version.

Reproduction

The recorded answer is one sample, so we re-ran the identical prompt 10 times. The 5 passages given were the same every time. All 10 reruns again said the documentation has no statement on production readiness. A sentence calling non-LTS lines suitable for some users, without the production rule, came back in 2 of 10 under a fixed wording rule, and one more rerun is borderline. The steady defect is the retrieval miss; the outright contradiction is intermittent.

Every failed answer, and how this sample was built

Every failed answer, in fix order

QQuestionFailure typeProbable stageWhat went beyond the sources
Q03Will Node 12.12.0 become a Stable LTS Release Today? (asked 2019-10-21; CC BY-SA 4.0)Wrong release factScope and decline rulesThe first Node 12 LTS release is expected to be a new minor release, 12.13.0, rather than 12.12.0 or 12.12.1 (flagged by the answer)
Q18What are the differences between Long Term Support (LTS) and Stable versions of Node.js? (asked 2015-11-11; CC BY-SA 3.0)Wrong policy or processRetrievalNode.js non-LTS lines suit users who can upgrade within months
Q01Why is node.js v4.4.5 recommended over v6.2.0 "for most users"? (asked 2016-05-30; CC BY-SA 3.0)Unsupported additionGenerationNode.js v4 was recommended over v6.2.0 because v4 was already in LTS at the time, while v6 wasn't (flagged by the answer)
Q04What happens when a NodeJS version reaches end of life? (asked 2023-05-04; CC BY-SA 4.0)Unsupported additionScope and decline rulesThe node-gyp failure to find python points to a build environment problem, not to Node.js end-of-life status (flagged by the answer)
Q05Difference between nodejs v0.12 and v5.x distributions (asked 2015-11-05; CC BY-SA 3.0)Unsupported additionNot assignedFor Node.js 26 the NodeSource Dockerfile line, following the same URL pattern, is: RUN curl -sL https://deb.nodesource.com/setup_26.x piped to bash - && apt-get install -y nodejs (flagged by the answer) (added in review)
Q08Which node version is good for upgrade from version 16? (asked 2023-10-12; CC BY-SA 4.0)Unsupported additionGenerationThe move to OpenSSL 3 in Node.js 17 and 18 caused compatibility issues for some applications
Q09How to check node LTS version of Node in terminal (asked 2024-01-19; CC BY-SA 4.0)Unsupported additionScope and decline rulesThe command nvm version-remote --lts prints the latest LTS version of Node.js (flagged by the answer); The command nvm ls-remote --lts lists all LTS versions of Node.js (flagged by the answer); The command nvm install --lts installs the latest LTS version of Node.js (flagged by the answer); node --version only shows the version of Node.js you have installed, not the latest LTS available
Q11Why Node.js 8 is recommended instead of Node.js 10? (asked 2018-09-27; CC BY-SA 4.0)Unsupported additionGenerationNode.js 8 was in LTS at the time Node.js 8 was recommended instead of Node.js 10, while Node.js 10 was not yet in LTS (flagged by the answer)
Q14How do I programmatically check the release status of the installed node.js version? (asked 2022-03-17; CC BY-SA 4.0)Unsupported additionGeneration, scope and decline rules, not assignedschedule.json is available at https://raw.githubusercontent.com/nodejs/Release/main/schedule.json (flagged by the answer); Using fetch in the node -e script requires Node 18 or later; node -p process.release.lts prints the codename on LTS builds of Node.js (flagged by the answer); node -p process.release.lts does not reveal end-of-life status (flagged by the answer); process.versions.node gives the installed version, whose major number (as v<major>) keys that line in schedule.json (added in review)
Q15Are there incompatibility risks when updating Node.js? (asked 2019-11-19; CC BY-SA 4.0)Unsupported additionScope and decline rulesNative addons often need rebuilding after updating to a new Node.js version (flagged by the answer)

Questions are quoted from Stack Overflow under CC BY-SA 3.0 or 4.0, by post date, each linked to its post. Usernames are removed.

The questions: a named frame, not live traffic

The frame, named before any answer was generated. Stack Overflow questions tagged [node.js], asked from 2015-09-08 to 2026-10-31, whose title mentions LTS or end of life, or whose title or body mentions LTS, end of life, EOL, long term support, release schedule, maintenance or active LTS, odd-numbered or security release: 1,056 questions. This is a stratum of real public questions, not live traffic to any assistant.

The screen. One stated rule, applied to every question in the frame before sampling: can the core of the question be answered from Node.js's own release, support, security or licence documentation? Install, configure and debug questions, third-party package vulnerabilities and other products' lifecycles are out. 20 questions passed.

The sample. A seeded random draw of up to 30 from the eligible questions returned all 20, so this is every eligible question in the frame, not a subsample.

Disclosed change. A first, narrower frame (from May 2018, without the bare "LTS" term) gave too few eligible questions. It was widened to the frame above before the assistant answered any question.

The assistant and its sources

Sources. 10 current Node.js documents, snapshotted on 2026-11-04: the Release Working Group README, its release schedule data and codename list; the nodejs.org Releases, End-Of-Life and Security Reporting pages; two nodejs.org blog announcements on the release schedule and the Node.js 16 end-of-life; and the Node.js security policy and a licence excerpt. Each is pinned to a commit (nodejs/Release 6065a83, nodejs/nodejs.org a2db8a5, nodejs/node 3b209b2).

Retrieval. The documents are split at headings into 126 passages, and keyword search (BM25) gives the top 5 to the model with each question.

Model. A current general-purpose model () with its default settings, instructed to answer from the passages, cite them, and say so when they do not contain the answer. The same model, with separate pinned prompts, splits answers into claims and proposes verdicts.

Planted document (planted arm only). The Release Working Group README as of 3 May 2022. It gives Node.js 16 an end-of-life of 30 April 2024, since moved to 11 September 2023, and the older release-plan wording. It has the same title as the current README, so neither the assistant nor the verdict step can tell it is planted. Nothing else was planted.

How the verdicts were decided

The harness split each answer into claims and proposed a verdict for each one, searching the whole snapshot before calling a claim not found. In the real arm, a separate AI review then decided every provisional failure, every claim where the sources disagree, every decline and every answer's verdict, reading each against the full source snapshot rather than only the passages the assistant retrieved.

No person confirmed these verdicts. In a client engagement, a person decides every verdict.

A statement about what the assistant found in its passages, a restatement of the user's own question, and advice that states no checkable fact are not claims. Where Node.js's own documents disagree with each other, the claim is left uncounted rather than called a failure.

What this sample does not show

This sample shows the report and the method on a small, fixed set. It does not include:

  • Omissions: what an answer should have said but did not.
  • Questions written to probe each failure type.
  • A second labelling pass after a gap, to show how stable the labels are.
  • A fix, and a before-and-after test on the same questions.
  • Agent actions or stated system state: this assistant only answers questions.

Measure how often your own assistant goes beyond your sources

This sample is our assistant on public documents. An audit measures yours on a random sample of your real conversations, starting with a short discovery call.

  1. Email or WhatsApp us
  2. Reply within 1 business day
  3. Free 30-minute discovery call
  4. Written scope and fixed fee within 2 business days of the call