Start from what you know: importing evidence agents can trust

Teams often ask an agent to “find out” something the organisation already knows. The signed contract sits in a shared drive, the pipeline is in a CRM export, the policy is a PDF that went round by email. The agent goes looking elsewhere, finds something adjacent, and answers with confidence. The fix is not a cleverer search. It is to hand the agent the material you already trust, labelled well enough that anyone can tell where each answer came from.

Why known material comes first

For many questions, your own documents are the authority. Your contract defines your notice period; an article about notice periods in general does not. Your export is the record of what was in the CRM; a third-party profile is someone else's account of it. Starting from known material does three things. It grounds answers in text you can open and check. It makes disagreements between sources visible instead of blending them. And it keeps the agent's work inside material you have already decided may be used.

That last point matters more than it looks. Choosing what an agent may read is a decision, and it is far easier to make well about a folder you know than about the open web. Deciding which sources may answer covers that choice in more depth.

What to bring, and what to leave out

Good candidates are documents people already treat as the reference: signed agreements, current policies and procedures, earlier reports that went through review, spreadsheets and system exports, meeting notes that recorded decisions, and web pages you rely on, saved at a known moment.

Leave out what would mislead. Superseded drafts with no marking, duplicate copies of the same file, and anything whose data classification does not fit the project all make answers worse. More material is not better if half of it contradicts the other half and nobody can say which version is current.

Attach provenance to every item

Provenance is what turns a pile of files into evidence. For each item, record at least where it came from, when it was taken, who owns it and which version it is. A small manifest is enough:

file: supplier-agreement-signed.pdf
origin: contracts drive / suppliers / signed
retrieved: YYYY-MM-DD
owner: procurement lead
version: signed copy, replaces draft 3
classification: confidential

file: vendor-pricing-page.html
origin: the original address of the saved page
retrieved: YYYY-MM-DD hh:mm
owner: market research
classification: internal

Web material needs this most. A saved page without its address and capture date cannot be checked later, because the live page may already say something different. Keep the original reference and the date with the copy, always.

Keep it inside one project

Import into the project the work belongs to, not into a company-wide heap. A project boundary keeps one client's documents out of another client's answers, and lets you set classification once for everything it holds. If two pieces of work need the same document, import it into both on purpose rather than widening one project to cover the other.

Read answers the right way

Once material is in place, answers should come back as passages with references to the documents they were drawn from. Treat each reference as a place to look, not a verdict: open it and confirm the passage means what the answer says it means. Two other outcomes are worth recognising. A search that finds nothing in your material is a genuine answer, and often a useful one. A search that could not run at all is something else, and should be handled as an outage rather than as absence. When values are pulled out of documents, a value the material does not contain should stay blank instead of being guessed. Citations that hold up and missing evidence is an open question go further on both points.

Refresh on purpose

Imported material ages. Contracts get amended, policies get revised, and an export starts going stale the day after it is taken. Silent, continuous syncing sounds convenient but makes it hard to say which version an answer relied on. A deliberate rhythm works better:

• Set a refresh cadence for each source, based on how fast it really changes.
• Re-import with a new retrieval date and mark the earlier copy as superseded rather than overwriting it.
• When a source changes, check which answers or deliverables depended on the old version.
• For outside sources that change often, watch them for change instead of re-importing on a hunch. Set a baseline before you monitor explains how to start.

How GoCux handles imported material

In GoCux, Knowledge search answers from a project's own documents and does not reach out to the open web. Web material arrives only by way of an authorised browsing or export step, and once imported it keeps the address of the page it came from and the date it was retrieved. Full-text search is available as soon as a document is in, with semantic retrieval adding to it when it is available. Results come back as passages with citations, and an empty result is reported as empty, which is kept distinct from a search that could not run. Extraction takes values from material you supply, ties each one to the passage behind it, and leaves a missing value marked unknown. Memory is no substitute for a fresh source either; memory with consent explains why remembered facts still need their sources refreshed.

Before you ask the first question

• The project holds the documents people already treat as the reference, and nothing that contradicts them without a marking.
• Every item has an origin, a retrieval date, an owner and a classification.
• Saved web pages carry their original address and the moment they were captured.
• Each source has a refresh cadence and a named person responsible for it.
• Reviewers know to open the cited passage, and know the difference between “nothing found” and “could not search”.