Skip to content

Pilot

How a pilot works

A pilot here is a joint project with a written definition of success and a deadline, rather than a trial that runs until someone loses interest. Below is the whole process, including what we need from you at each step.

Two small figures at the base of an archway, looking forward together

  1. Tier 0 · One to two weeks

    Grounding teardown

    You give us a narrow slice of your real corpus and a list of the questions your current AI tools answer badly. We run those questions through the grounding service and through your existing setup, and we show you side by side where ordinary retrieval drops context, returns the wrong passage, or cannot answer a whole-corpus question at all.

    It is deliberately small and time-boxed, because its job is to establish whether the problem you have is the problem we solve. If it is not, we will tell you, and that is a useful outcome rather than a failed sale.

    What you get
    A short written teardown: the specific questions, the specific failures, the coverage reports, and a clear read on whether the grounding service is built for your problem.
    What we need from you
    A hand-picked slice of real documents and a fixed set of questions you already know are answered badly.

  2. Tier 1 · Four to eight weeks, fixed

    Scoped pilot

    We stand up a galvanically separated instance on your preferred cloud, ingest a real and bounded body of your documents, and connect it by API into one of the AI tools your team already uses. One corpus, one team, one integration. Everything else is expansion, which is a later conversation.

    Success criteria are written with you before any work begins, in your metrics rather than ours, and signed off by everyone who will later be asked to approve a purchase. The question set is agreed in advance, including the hard ones, so the evaluation cannot move afterwards. Data access and security review happen at scoping rather than surfacing at the end.

    There is a fixed end date and an explicit go or no-go decision at it, with the expansion terms already drafted so a yes has somewhere to go.

    What you get
    Measured performance against an agreed baseline, the coverage reports that show sufficiency, a working API integration, and a short value memo your champion can take to their own stakeholders.
    What we need from you
    A named owner who can sign, a bounded corpus, one integration point, and agreement on what success means before we begin.

  3. Tier 2 · Three to six months

    Design partner

    A longer arrangement with a small number of teams willing to shape what gets built. In exchange for early and preferential terms and a formal voice in the roadmap, you commit real usage, a named internal champion, and a public reference if the work lands.

    This is the right shape when your requirements are ahead of the product, which is often the case for interactive systems and agents, where the latency and memory profile differs from the document work.

    What you get
    A co-built solution for your priority use case, a reference and case study, and direct influence over what we build next.
    What we need from you
    Real usage, a named champion, and a willingness to be referenced.

What we settle before the work starts

Most pilots that fail do not fail on the technology. They fail because success was never defined, or because a data access problem surfaced after the technical work was finished. So these are written down before anything is ingested.

  1. Success criteria, in your metrics

    The specific questions the system has to answer well, what well means to you, and the business outcome it ties to. Agreed by everyone who will later approve a purchase.

  2. The question set

    A concrete, bounded list of the queries the pilot is judged on, including the whole-corpus ones, the comparisons, the as-of-when ones, and the ones your current tool fails.

  3. The corpus slice

    Exactly which documents, from where, owned by whom, and the smallest slice that still makes the test real.

  4. Data and security red lines

    What cannot leave your environment, what needs masking, and what stays out of scope. Your IT and security people are in the room for this, not shown the result afterwards.

  5. The integration point

    Which one of your existing AI tools we connect to by API. One, not several.

  6. The timebox and the decision

    A fixed end date and an explicit go or no-go, with expansion terms drafted in advance so a yes does not restart the negotiation.

If you have a corpus and a set of questions your current tools get wrong, that is enough to start a conversation. We will tell you when grounding is not the answer.

Talk to us about a pilot