Validation Metadata
Validation metadata exists at more than one level because Technical Sessions, validated workflows, and prepared implementation packages have different responsibilities. Do not assume one universal response.validation object.
Technical analysis
Each technical_analysis.analyses[] packet can include:
| Field | Current meaning |
|---|---|
validation_status.grounded | At least one finding or risk is connected to supplied evidence. |
validation_status.official_documentation_used | At least one analysis source is marked official. |
validation_status.conflicting_sources_detected | Upstream validation context contains unresolved conflict. |
validation_status.human_review_recommended | Risk, missing grounding, conflict, security sensitivity, or upstream review context recommends review. |
validation_status.validation_level | strong, moderate, or limited. |
confidence | Analysis confidence from 0 to 1; current generation uses bounded values based on evidence and conflict state. |
assumptions / unknowns | Explicit limits of the analysis. |
risks / findings | Structured items with severity, evidence, mitigation or recommendation, and item confidence. |
Workflow validation
Validated technical workflow packets use validation_summary with grounded, official_documentation_used, conflicting_sources_detected, validation_level, and human_review_recommended. Workflow packets can also include confidence_dimensions and confidence_factors copied from the canonical implementation package.
Implementation-package validation
An implementation package uses validation.human_review_required, validation.human_review_reasons, validation.confidence, validation.confidence_dimensions, and validation.confidence_factors. It can also carry assumptions, unknowns, blocking_unknowns, and a preparation status.
These package structures are returned through workflow/artifact content but are not yet fully described by the public OpenAPI response schemas. Use defensive access and see Validation Responses.