Ball Valve Engineer Guide

Use this section when reading ball valve results. Ball valve output is evidence-gated and nested. A technically interesting row is not automatically actionable.

How To Read A Ball Valve Result

1. Check top-level status before reading rows.
2. Check candidate_evaluation_status.
3. Confirm the reference is attached and confirmed.
4. Read match_result.results as flat row evidence.
5. Read summary.grouped_output_contract and PipelineResult.presentation for grouped display.
6. For each row, check class, technical_fit_class, original_public_class, and display_label.
7. Check procurement_release_allowed, procurement_blockers, public_recommendation_allowed, and qualified_alternate.
8. Read field_proofs, evidence_contract, core_gate_report, service_overlay_report, and modification_report.
9. Follow recommended_next_action.

Do

• Do treat DROP_IN with procurement_release_allowed=true and no blockers as the only procurement-ready result.
• Do treat FIT_OR_BETTER as still evidence/procurement-gated.
• Do treat PROBABLE_DROP_IN as advisory and not procurement-ready.
• Do treat REQUIRES_MODIFICATION as requiring named modification, approval, and verification.
• Do use grouped presentation to explain manufacturer/brand grouping.
• Do keep flat rows and grouped rows conceptually separate.
• Do explain blockers directly.
• Do ask for datasheet/nameplate/OEM orderable code when reference is weak or ambiguous.

Don’t

• Do not flatten ball valve output into a simple class list.
• Do not call discovery rows replacement candidates.
• Do not call PROBABLE_DROP_IN procurement-ready.
• Do not recommend modification without approval/MOC/verification routing.
• Do not treat AMBIGUOUS_MATCHES, INPUT_RECHECK_REQUIRED, or NO_REFERENCE as actionable.
• Do not ignore candidate_evaluation_status.
• Do not hide procurement blockers behind a positive technical class.
• Do not call a reject proven unless the hard boundary is actually proven.

Status Next Actions

Status	Engineer action
OK	Read row class, evidence contract, blockers, and procurement release flags.
AMBIGUOUS_MATCHES	Treat rows as confirmation/discovery only; ask for exact OEM orderable code, datasheet, nameplate, or decisive specs.
INPUT_RECHECK_REQUIRED	Resolve conflicting or weak input before evaluating candidates.
NO_REFERENCE	Request reference evidence; do not evaluate replacements.
ERROR	Treat as no technical result; retry or escalate.

Class Next Actions

Class	What to do next
DROP_IN	Confirm procurement_release_allowed=true, no blockers, and closed evidence before recommending.
FIT_OR_BETTER	Check evidence and procurement gates; explain upgrade/specialization path.
PROBABLE_DROP_IN	Request missing proof; do not release for procurement.
REQUIRES_MODIFICATION	Confirm named modification path, approval, verification, and MOC requirements.
POSSIBLE_MODIFICATION_PATH	Treat as discovery; collect modification evidence.
ENGINEERING_CONFIRMATION_REQUIRED	Route to engineering with missing evidence/blockers.
PROBABLE_TECHNICAL_MATCH	Use for discovery only; confirm reference and decisive specs.
REJECT	Confirm hard boundary evidence before presenting as final rejection.

Field Next Actions

Field	What to do next
candidate_evaluation_status = DISCOVERY_ONLY	Use rows only to clarify identity or direction.
candidate_evaluation_status = NOT_EVALUATED	Do not treat rows as evaluated replacements.
procurement_release_allowed=false	Do not recommend for procurement.
procurement_blockers not empty	Explain each blocker and collect required evidence.
evidence_contract open or failed	Close decisive field proof before recommending.
field_proofs missing decisive proof	Request datasheet/nameplate/OEM source for that field.
modification_report incomplete	Do not recommend modification route yet.
recommended_next_action present	Use it as the next human step.

Grouped/Nested Result Workflow

1. Start with top-level status and summary.
2. Use summary.grouped_output_contract to understand whether public replacement counts are allowed.
3. Use PipelineResult.presentation for grouped display by manufacturer and brand.
4. Drill into flat results[] rows for evidence and blockers.
5. Never let grouped placement imply procurement readiness.

Example Workflow

When a row is PROBABLE_DROP_IN but procurement_release_allowed=false:

1. State that the row is a likely technical direction, not a release candidate.
2. Read procurement_blockers.
3. Identify which field_proofs are missing or non-decisive.
4. Ask for OEM datasheet, nameplate, rating, end connection, size, or service evidence.
5. Re-evaluate only after evidence is closed.

Never Claim

• Never claim “drop-in ball valve” from nominal size and end connection alone.
• Never claim procurement readiness without procurement_release_allowed=true.
• Never claim modification is acceptable without named approval and verification route.
• Never claim discovery results are evaluated alternates.