Documentation Quality in DocsFab

Documentation quality combines evidence about factual trust, reader understanding, and task success in DocsFab. No single check establishes all three.

Use these separate results to decide what still needs verification or review. A workflow can finish while its evaluation reports failure or insufficient evidence. Execution completion, document quality, and publication approval remain separate decisions. For related concepts, refer to Core Concepts.

Three Quality Questions

DocsFab judges quality in three cumulative layers. Each layer asks one question:

1. Trustworthy information: Can this information be relied on for its declared scope?
2. Transferable understanding: Does the documentation help the reader form a coherent model and reason beyond memorized wording?
3. Effective experience: Can the intended user find and apply the right information with acceptable effort, risk, and friction in the actual workflow?

A higher layer cannot make up for a failure in a lower layer. A polished experience cannot make an incorrect command acceptable. Critical factual errors, unsafe instructions, wrong-version behavior, unsupported consequential claims, and material omissions are failures that no other strength can offset.

Quality is a set of results, not one score. A high average must never hide a critical accuracy, security, accessibility, or task-safety failure.

What Each Check Can Show

Each check answers a different question and has its own limit. The following table describes them.

Review must be independent of authorship. Documentation that DocsFab writes is reviewed by a clean reviewer that did not take part in writing it, and same-session self-review cannot satisfy that requirement. A finding closes only when it is fixed and verified, or when an authorized owner dismisses it with an explicit rationale. For the roles and the independence rule, refer to Review Independence.

For the evaluation artifacts that a run produces, refer to Evaluate Document Quality Skill in DocsFab.

Reading a Result

The current docsfab-documentation-quality profile, version v0.1, is experimental and has release_gate_eligible: false. It cannot produce an overall release-gating pass. A rubric score, when available, is a separate view and does not override the layered result.

The following three results are easy to confuse, and each means something different:

• fail: DocsFab established a failure, such as a required command that does not work.
• insufficient-evidence: Evidence about quality is missing, such as audience testing that could not run.
• needs-input: Evidence about the product is missing, so DocsFab cannot write the page without inventing facts.

The following fictional example shows how to read a report.

Evidence Before Drafting

DocsFab does not ask whether its product knowledge is universally complete. It asks whether the available evidence is good enough to create one high-quality page for a named audience and release. Different page types need different evidence, as the following table shows.

If a load-bearing requirement is absent, DocsFab records needs-input instead of converting uncertainty into confident prose. The NVIDIA documentation families are the default structure, and your organization can supply another structure without changing this rule.

Next Steps

To continue, refer to the following pages:

• Baseline Documentation Health in DocsFab
• Run a Documentation Workflow in DocsFab
• Evaluate Document Quality Skill in DocsFab
• Test Audience Understanding Skill in DocsFab
• Quality Roles and Capability Coverage in DocsFab