The right solution depends on what is missing from the current workflow.
We assess your current repository before recommending a separate system. Search quality does not replace document control or an engineer’s review.
Evaluate before wider rollout
We work through the questions, access rules and failure cases with your team before expanding the scope.
The existing guide includes a 40-question test set and an editable scoring workbook. Record the expected source, answer correctness, citation quality and permission result separately. An unsupported answer should be marked as a failure even when it sounds plausible.
Open the engineering evaluation guideDownload the evaluation workbookDelivery evidence
TCE · Infrastructure
For TCE, we built document search with citations, highlighted evidence and access controls around bid packages that can reach 5,000 to 50,000 pages. The system is in production and still used by the team.
Based on engineer interviews and client estimates, including time to read the AI answer. These figures were not measured through usage logs or a controlled pilot and are not a promised result for another team.
How we work
Each week covers whatever the project needs most: planning, design, development or testing. We start with your workflow and goals, agree what to tackle first, and adjust priorities together as the work takes shape.
Each completed phase includes 30 days of bug fixing at no extra charge. Ongoing maintenance, AI tuning, and new improvements are scoped separately.
FAQ
Not necessarily. We first check whether your existing repository and search tools can meet the need. Custom search may fit when engineers need answers across a document set with exact source references, revision rules and access controls. Retention, approvals and document ownership may need a different improvement.
We evaluate representative questions against answers and source passages reviewed by your engineers. Tests cover missing evidence, conflicting revisions and questions the system should decline to answer. A fluent response does not count as a correct answer.
We inspect representative files before defining the scope. Scans may need text extraction, tables need their structure preserved, and revisions need a rule for which document applies. We test these separately rather than assuming every file will work equally well.
We agree who can access each document set and test retrieval with users who should and should not see it. Answers, citations and previews must respect those access boundaries, including after access is revoked.
With a conversation about your workflow and what needs to change. From there we work week by week, covering planning, design, development and testing, and agree priorities together as we go.
The first-release scope, user roles, data quality, integrations, AI evaluation, design work, and deployment requirements determine the effort. Access, feedback, and third-party dependencies also affect timing. We share an initial estimate once we understand the work and revisit it with you as priorities change.
An owner who can make decisions, examples of the workflow and exceptions, access to the relevant systems and data where appropriate, and people who understand the users. We agree the inputs and review points before work starts. A complete technical specification is not required.
Marketing execution, staff augmentation, and unlimited revisions or support are outside our standard product-build engagement. We agree together what each phase includes.
Each completed phase includes 30 days of bug fixing at no extra charge. Ongoing maintenance, AI tuning, and new improvements are scoped separately.
Start with a description of the document set, a few questions your team struggles to answer and the access rules that matter. We will discuss what to evaluate first and agree how any sensitive examples can be shared.
Discuss your document search