NVIDIANVIDIA-Certified Professional: Agentic AI2026-106.4 Conduct data quality checks, augmentation, and preprocessing.
Admit documents through independent quality checks
Completed by the knowledge check
Learning objective
Run data quality checks for completeness, validity, freshness, and PII.
Core idea
A document can be well formed, complete, and unsafe to publish. It can also contain no personal information yet describe a superseded policy. Treat completeness, validity, freshness, and personally identifiable information (PII) as separate admission decisions. An average quality score cannot compensate for a failed mandatory check.
Produce a per-document quality record containing the source identifier, source revision, check results, rule version, and disposition. Those are application-defined fields, not a built-in NVIDIA schema. They connect the checks to the document that is actually admitted. Text repair and duplicate handling belong to 6.4.1; this lesson decides whether the resulting document is usable for its intended audience.
How it works
Check completeness against an expected inventory
Completeness asks whether required information arrived. Check two levels: expected documents versus received documents, and required fields or sections inside each document. A nonempty collection does not prove that every source department or policy revision is represented.
NVIDIA RAG Blueprint implements metadata presence checks through collection metadata_schema entries with required: true. During ingestion, it rejects documents missing required metadata and returns detailed errors. Declare the fields the consuming workflow needs, such as a source revision or jurisdiction, before submitting custom_metadata. Adding an undeclared field is also an ingestion error; correct the metadata or explicitly update the collection schema.
Presence does not establish coverage. Reconcile admitted source IDs against the upstream export inventory and retain the missing-ID list as a release artifact. If an export promises 240 policies and only 232 are admitted, report the eight missing documents even when every admitted row satisfies its schema. The ingestion team owns recovering the absent records; the domain owner decides whether the affected assistant capability can operate with that gap.
NeMo Curator’s ScoreFilter with WordCountFilter can identify suspiciously short extracted text. Its min_words and max_words are document-length controls, not proof that every page or section was extracted. A short eligibility rule might be complete, while a long policy can omit its exceptions table. Set length checks by document family and inspect rejects before applying them across the corpus.
Check validity against the intended meaning
Validity asks whether values satisfy their required representation and business rules. RAG Blueprint validates metadata types, array elements through array_type, and configured string or array length through max_length. A revision represented as text is different from a date represented by a datetime field; choose the schema according to how the consuming workflow uses it.
Then add explicit application checks for domain relationships: an effective end must follow its start, a policy code must exist in the source registry, and an extracted benefit amount must match the source table. Record which comparison failed in the quality record. Correct the field mapping or re-extract the source rather than coercing an invalid value merely to pass the schema.
Keep structural and semantic checks distinct. A valid integer can be the wrong benefit amount. A plausible paragraph can contradict its attached source. Where meaning requires judgment, use a reviewed comparison to source material rather than interpreting a schema pass as factual verification. Semantic judging of generated augmentation is covered in 6.4.3.
Measure freshness from the source state
Freshness asks whether the document remains suitable at the time of use. Give the quality record separate application fields for source_updated_at, ingested_at, checked_at, and the source revision. Re-ingesting a three-month-old export today changes ingestion time without proving that the upstream content is up to date.
Define the acceptable source age per document family and compare it at admission. A 24-hour threshold for daily benefits rules and a 30-day threshold for a reference handbook are example operating policies, not NVIDIA defaults. Also compare the expected revision against the source inventory: a record modified within the age limit can still refer to a withdrawn policy.
RAG Blueprint supports datetime metadata, but the team must implement the source-age comparison and effective-date rule. Store those values in declared metadata fields when downstream retrieval needs them. If the source timestamp is missing or cannot be trusted, mark freshness unknown and apply the collection’s admission policy. Do not silently replace it with ingestion time. Streaming updates and resolving live stale conflicts belong to 6.5.3.
Check PII before storing broadly accessible text
NeMo Guardrails exposes the asynchronous detect_sensitive_data(source, text, config) action, returning RailOutcome.block() when it detects sensitive data and RailOutcome.allow() otherwise. A preprocessing adapter can check candidate text using source="input" and translate the result into a storage disposition; use a separate RailsConfig for that adapter so runtime input-rail changes do not silently change admission.
Set the detector’s entity list through rails.config.sensitive_data_detection.input.entities; raising its score_threshold reduces false positives but can miss more sensitive examples. Runtime PII rails, entity configuration, and detector tuning belong to 9.2.1. In the v0.24.1 implementation, this direct action uses spaCy’s en_core_web_lg and calls the analyzer with language="en": this path covers English text, not a multilingual corpus.
EMAIL_ADDRESS detects addresses without deciding whether they are personal or approved published contacts. Route matches to a documented review or masking disposition rather than rejecting every document that contains a public contact address. mask_sensitive_data can return RailOutcome.transform() with altered text; validate that text before admission. The retrieval rail (see 9.2.1) acts at query time, not at write time.
Key distinctions and trade-offs
Use independent results rather than one compensating score:
| Check | Deciding question | Mechanism or artifact | Typical remedy and cost |
|---|---|---|---|
| Completeness | Did all required content arrive? | Source-inventory reconciliation; required: true | Recover missing documents; delay affected coverage |
| Validity | Are representations and relationships acceptable? | Metadata type checks; source-registry comparisons | Repair mappings or extraction; extra comparisons |
| Freshness | Does content meet its allowed source age and revision? | Source timestamp and revision admission rule | Refresh or exclude stale content; reduced availability |
| PII | Is content suitable for this audience? | detect_sensitive_data; configured entities | Quarantine or approved masking; detection and review cost |
Keep unknown separate from passed. A missing timestamp, detector failure, or unavailable source registry leaves a check unresolved. The quality record should preserve that state so operators can repair its cause instead of celebrating an apparently lower rejection rate.
Architecture / decision scenario
A benefits provider launches an English-language employee assistant with a daily 06 publication deadline. Its inventory contains 240 policy documents. A staging run receives 240, but eight lack a required jurisdiction, six contain invalid effective-date relationships, and four exceed the team’s 24-hour source-age limit. These groups are disjoint. Of the remaining 222 documents, two expose personal email addresses; the detector also flags the published benefits mailbox throughout the collection.
The delivery lead proposes admitting everything because average field completeness exceeds 95%. The benefits data owner rejects that alternative: the assistant must answer eligibility questions by jurisdiction and effective date, and personal email addresses cannot enter the employee-wide index.
The ingestion team repairs metadata and date mappings and requests fresh exports for the four stale sources. It routes email matches to review against the source owner’s approved contact list, retaining approved public contacts and quarantining the two personal-address cases for masking. The other 220 become eligible after those reviews. The team reconciles admitted IDs against all 240 expected sources and reports uncovered policy families; the product owner can restrict the launch to covered families rather than admit unresolved documents.
Common exam traps
- Treating required-field presence as proof of complete source coverage.
- Treating a type-valid value as a factually correct one.
- Measuring source freshness from the time of ingestion.
- Raising a detection threshold without measuring missed PII.
- Counting an unresolved check as a pass.
- Assuming a retrieval-time mask prevents sensitive text from being stored.
What to remember
Use separate admission results for completeness, validity, freshness, and PII. Name the source inventory, metadata schema, timestamp comparison, and detector configuration that implement them. A failed check needs a specific repair owner, and an unknown result needs an explicit disposition.
Knowledge check
An export promises 240 policy documents. The collection admits 232, and every admitted document satisfies the required: true metadata fields of its metadata_schema. The delivery lead calls the collection complete. Which check reveals the gap?
metadata_schemaWordCountFilter minimum applied to every admitted documentA family of daily benefits rules has a 24-hour source-age limit. Thirty of its documents, re-ingested this morning, arrive without a source update timestamp. What should their quality records show for freshness?
PII detection with EMAIL_ADDRESS flags the published benefits mailbox in nearly every document of an employee-wide collection, and two personal email addresses in two documents. Personal addresses must not enter the index, and approved public contacts must remain available. Which disposition fits?
score_threshold until the mailbox no longer matchesEMAIL_ADDRESS from the configured entities listEMAIL_ADDRESS detects addresses without deciding whether they are personal or approved public contacts, so the matches need a documented review that keeps the approved mailbox and quarantines or masks the personal addresses. Raising the threshold reduces false positives at the risk of missing personal addresses, removing the entity stops the check, and rejecting every match discards the collection for a public contact.A team checks candidate text with Guardrails’ v0.24.1 detect_sensitive_data action before admission. The corpus adds 3,000 Spanish documents to an English collection, and the action returns allow for most of them. Every admitted document needs a resolved PII result. What should happen to the Spanish documents?
allow result the action returnedscore_threshold for the Spanish documents onlymask_sensitive_data and admit the output texten_core_web_lg and analyzes with language="en" , so it covers English text, not a multilingual corpus. An allow from a path that does not cover the language is not a pass; it leaves the check unresolved, and tuning the threshold or masking with the same detector does not extend its coverage.A benefits document passes the collection’s metadata type checks: its benefit_amount is an integer. A source comparison shows that it belongs to a different policy tier. How should validity be recorded and addressed?