bench-query

Bench Query

Purpose

Turn bench exports, profile data and the conflicts register into bench_candidates[] and normalized constraints[] with the fields the deterministic engines need.

When to use

After role-intake, before fit-score, for every staffing slate.

When NOT to Use

• Writing job postings or recruiting copy for external hires.
• Computing fit scores, effective capacity or utilisation after staffing — use fit-score instead.
• Deciding eligibility, conflicts or independence — bench-query normalizes the records, but constraint-check alone decides the verdict.
• Drafting the staffing recommendation — use slate-draft instead.

Inputs

• Resource management system roster or bench CSV.
• HR profile data for skills, certifications, seniority, location and languages.
• Availability calendar, approved leave and soft-booked pursuits.
• Rate card or candidate billing-rate export.
• Conflicts register and ethical-wall extract for every candidate, including clear records.

Steps

1. Normalise candidate IDs, names, seniority, skills, certifications, industry experience, location, languages and rate. Preserve the display ID, but match IDs in the canonical form of independence-eligibility-rules.md #9.5. Parse CSV exports tolerantly (leading spaces before quoted fields).
2. Carry current allocation, target utilisation, approved leave blocks and soft bookings exactly as records (start, end, allocation_pct, citation), even when current allocation is 0%. target_utilization_pct is planning context only; it does not change effective available capacity.
3. Copy the engagement{} block from role-intake unchanged into both bench.json and constraints.json, and copy the complete roles[] block into constraints.json. Include an explicit affiliates[] array and preserve the role-intake source, confidence and citation. Never replace SOW-derived affiliate provenance with conflicts-register provenance.
4. Normalize every conflicts-register row into constraints[] with candidate_id, type, client_name, status, material, role_type, process, end_date, resolved_date, source, confidence and citation. Include at least one row for every candidate, including explicit clear rows. Preserve unknown types and blank fields; never drop or reinterpret them. A blank optional cell may be omitted (the engine reads an absent field as blank) but never filled with a default; material true/false becomes a boolean.
5. Preserve provenance with this deterministic ladder: use 0.98 when all required sources agree and freshness is verified; 0.97 when all required sources agree but one field comes from a secondary authoritative source; 0.96 for a complete authoritative export with standard enrichment but no independent freshness verification; 0.95 when the export is complete but profile enrichment is absent; below 0.75 when required fields conflict or are stale. Use the same value for every record in the same evidence tier; do not invent intermediate values. Clear rows still require provenance.
6. Hand bench.json to fit-score and constraints.json to constraint-check.