Senior Search / Information Retrieval Engineer — OEM Technical Document Retrieval

Project Overview I am looking for a senior engineer with strong information-retrieval, search, and technical-document discovery experience to complete a specific retrieval milestone for an industrial maintenance software application. The problem is narrowly defined: Given industrial equipment identity information such as manufacturer, model, serial/configuration information, and equipment type, reliably locate and acquire the correct publicly available OEM technical publication applicable to that equipment. Examples include OEM operating manuals, installation/operation/maintenance manuals, service manuals, maintenance manuals, and equivalent controlling technical publications. This is not a general software-development project and not primarily a prompt-engineering project. Substantial engineering work has already been completed. The project includes an existing retrieval implementation, test assets, telemetry, benchmark results, governance requirements, and extensive root-cause analysis (RCA) and documentation of previous experiments. The successful contractor is expected to use that evidence rather than repeat previously completed investigation without a specific technical reason. The Engineering Problem The existing system can successfully locate difficult OEM publications and has strong controls around source evidence, publication authenticity, equipment applicability, and fail-closed behavior. The remaining challenge is making retrieval consistently reliable and fast across both straightforward and difficult cases without weakening those controls. Recent testing on a fixed four-equipment control set produced successful retrievals in approximately 40–74 seconds per asset. However, those cases followed relatively easy retrieval paths and do not establish that the retrieval problem is solved. Historically, difficult and long-tail cases have required substantially more retrieval effort and time. The objective of this engagement is to complete the FIND milestone and prove that it works against an agreed acceptance test, including difficult retrieval, long-tail/archive behavior, and correct refusal when an applicable public OEM publication cannot be validated. Non-Negotiable Requirements The completed FIND system must: Locate the correct applicable OEM publication when it is publicly obtainable. Preserve evidence showing where the publication came from. Validate OEM identity and equipment/model applicability. Acquire and inspect the actual publication rather than treating search-result snippets as proof. Support legitimate long-tail and archived-publication retrieval. Fail closed when sufficient evidence cannot be obtained. Produce no invented, unsupported, or incorrectly applicable publication releases. Preserve defined downstream interfaces and existing validation controls unless a change is explicitly approved. Provide reproducible telemetry showing what the retrieval system did and where time/resources were consumed. Avoid benchmark-specific hardcoding or leakage. Demonstrate improvement using controlled testing rather than anecdotal examples. Safety and evidence integrity take precedence over retrieval rate. If a publication cannot be sufficiently validated, the correct result is a refusal. Scope This engagement is specifically for the FIND/retrieval milestone. It does not include mobile application development, UI work, downstream preventive-maintenance extraction or generation, or unrelated application development. The repository contains an existing FIND implementation, test harnesses, historical benchmark results, failed-experiment documentation, telemetry, RCA artifacts, and control assets. Initial Paid Milestone The engagement will begin with a short, fixed-fee technical review. The contractor will: Review the supplied governance, technical handoff, relevant RCA, and benchmark evidence. Inspect the existing FIND implementation and relevant artifacts. Reconstruct and verify the current retrieval flow from the actual implementation. Review previous experiments and identified failure modes. Identify material telemetry or evidence gaps, if any. Provide a concise technical assessment of the remaining bottleneck. Recommend the smallest defensible path to completing FIND. Provide a proposed fixed price and level of effort for the completion milestone. This is intended to be a focused technical assimilation and decision exercise, not a lengthy discovery project. Existing RCA and experimental evidence is project input. Repeating previously completed analysis or experiments without identifying a new independent variable or explaining why the existing evidence is insufficient will not be considered productive milestone work. No material implementation changes should be made during this milestone without approval. Completion Milestone Following successful completion of the technical review, the second fixed-fee milestone will cover implementation and proof of the agreed FIND solution. Final acceptance criteria will be established from the supplied technical documentation and control/benchmark assets before implementation begins. Acceptance will include measured performance in: Retrieval correctness Equipment/publication applicability Evidence integrity Correct fail-closed behavior Zero new unsafe or unsupported releases Long-tail/archive preservation Wall-clock performance Retrieval/resource work Reproducibility Regression performance A solution that is faster only because it weakens evidence requirements, eliminates legitimate long-tail retrieval, hides work outside measurement, or hardcodes benchmark knowledge will not be accepted. Deliverable and Integration Requirements FIND will be developed and proven outside the production mobile applications. Android and iOS integration are explicitly outside the scope of this engagement. The final deliverable must be integration-ready. It will subsequently be integrated into Android and iOS by others, without assistance from the contractor. Ease of integration is therefore an acceptance requirement, not merely a documentation preference. The completed FIND milestone must include: Executable, production-quality source code within the supplied isolated research environment. One clearly defined and documented programmatic entry point. A stable, machine-readable input/output contract. Explicit handling of successful retrieval, validated refusal, error, and timeout conditions. No manual research, notebooks, developer intervention, or contractor-operated steps during normal execution. All dependencies, configuration, external services, credentials/interfaces, timeouts, and runtime assumptions explicitly documented. No undocumented local dependencies, hidden services, or contractor-specific infrastructure. Automated tests covering the integration interface and expected behavior. Reproducible setup and execution from a clean environment. Sufficient interface and implementation documentation for developers unfamiliar with the contractor's work to integrate FIND without additional explanation. A final handoff package containing source code, interface specification, configuration/dependency requirements, setup instructions, test instructions, acceptance evidence, known limitations, and unresolved risks. The reference implementation should remain compatible with the existing Python-based isolated research environment unless an alternative is proposed during the initial technical review and explicitly approved. The contractor must design the integration boundary on the assumption that they will not participate in the subsequent Android or iOS integration. A technically successful FIND implementation that requires substantial reverse engineering, restructuring, or contractor assistance to integrate will not satisfy the milestone requirements. Production Android and iOS application code must not be modified as part of this engagement. Communication and Delivery Expectations Technical ability alone is not sufficient for this engagement. Communication, ownership, and reliable execution are requirements. The contractor will be expected to: Establish a time-bound communication cadence at the start of the engagement and adhere to it. The cadence must define when progress updates will be provided, how blockers will be escalated, and when the next committed deliverable or decision point is expected. Establish clear deliverables and realistic dates before committing to them. Develop and maintain a concise risk register throughout the engagement. Risks, issues, technical blockers, dependencies, failed approaches, and unexpected results should be captured as they are identified, including impact, mitigation/next action, owner, and current status. Material changes in risk must be communicated promptly rather than waiting for the next scheduled status update. Meet self-committed deadlines. If a date becomes at risk, communicate that before the deadline, explain why, and provide a revised recovery plan. Provide concise, substantive progress updates during active work. I should not need to repeatedly request project status. Maintain a concise decision/change log. Proposed changes to agreed scope, acceptance criteria, control assets, validation gates, or material architecture assumptions must be documented and approved before implementation. Maintain clear evidence of what was changed, what was tested, what passed or failed, and what remains unresolved. Take ownership of the agreed milestone rather than waiting for detailed day-to-day task management. Be direct when evidence shows an approach is not working. An early, well-supported negative result is preferable to losing time pursuing an approach that cannot meet the requirements. Milestones are complete only when the agreed deliverables and acceptance evidence have been provided and reviewed. Code completion, a successful demonstration, or elapsed effort alone does not constitute milestone acceptance. Missed commitments without advance communication, failure to maintain the agreed communication cadence or risk register, extended periods without meaningful status, unauthorized changes to agreed scope/acceptance criteria, or repeated failure to manage agreed work will be grounds for ending the engagement. I will be responsive and available when decisions or clarification are required. In return, I expect professional project management and communication from the contractor. Experience I Am Looking For Strong candidates will have significant hands-on experience with several of the following: Information retrieval and search infrastructure Technical-document or publication discovery Web search APIs or SERP-based retrieval systems Crawling and targeted document acquisition HTTP and PDF acquisition pipelines Candidate ranking and relevance scoring Metadata/document indexing Manufacturer/domain-specific search Archive.org / Wayback / CDX-style retrieval Identity/entity resolution Deterministic retrieval orchestration Python Instrumentation and performance measurement Bounded use of LLMs within retrieval systems Experience building real search/retrieval systems is considerably more relevant than experience writing prompts or building generic RAG applications. Availability This is an expedited engagement. I am looking for someone who can start quickly and give the project concentrated attention through completion. I am not looking for a contractor who can only contribute a few hours per week over an extended period. Please state your realistic availability and earliest start date. Application Questions Please answer each question directly: Describe the most technically similar search, retrieval, crawling, or document-discovery system you personally designed or implemented. What specifically did you build? How would you approach a retrieval system where common documents may be easy to find, but difficult cases can involve ambiguous equipment identity, poorly indexed OEM sites, obsolete publications, distributor-hosted copies, or web archives? How would you prove that a retrieved technical publication actually applies to the requested manufacturer/model rather than merely being topically related? What telemetry would you require before attempting to optimize retrieval latency? Based on this description, what is the largest technical uncertainty you would want to resolve first? What fixed price would you propose for the initial technical-review milestone? Based only on the information in this posting, what preliminary level-of-effort range would you expect for completing FIND? State your assumptions. This is not a request for a binding implementation quote. What is your earliest start date, and how many hours can you realistically dedicate during the first two weeks? Will you personally perform the work? If other people will participate, identify their roles. Describe how you normally communicate progress on a short, technically uncertain project. If you realize on Wednesday that a Friday commitment is going to slip, what specifically do you do? Please do not submit a generic proposal. I am much more interested in concise evidence of directly relevant engineering experience and how you think about this retrieval problem.