Define the question before connecting the source
A database connection is a capability, not a reason to expose everything it contains. Write down the first question the application should answer: finding open orders, locating a purchasing policy or explaining a cost difference. Select the sources and fields needed for that question. Where information exists in several systems, agree which record takes precedence with the business owner. The application should not silently choose between conflicting customer records. Identify who owns the source, who authorises access and who will use the answer. A small, explicit inventory often uncovers more useful questions than an early demonstration with unrestricted access to the entire company archive.
Show what freshness means for this answer
A file's modification date may differ from the effective date of the policy inside it. An ERP record, an overnight extract and a search index may also describe different moments. Decide which dates matter to the reader: when the source changed, when the application retrieved it and which business period it covers. A closed-period report and today's operational movements should not imply the same freshness. Agree what happens when a refresh fails, including whether an older copy may still be used and how it is labelled. For decisions that depend on current information, stopping with an explanation can be more useful than returning a plausible answer from stale records.
Carry access boundaries through the whole request
Signing in to an application does not give someone permission to read every company document. Access design needs to account for the person, the relevant company or department and the requested operation. OWASP's authorization guidance recommends least privilege and checking permissions on every request. Hiding interface buttons does not provide that boundary. Search results, document excerpts, caches and exported reports need to respect it too. Ask the same question as people with different access and inspect what each receives, including record titles and short snippets. Also establish how a permission change takes effect; a previously retrieved copy should not quietly create a permanent exception to the access policy.
Begin with a useful read-only task
Make the first connection useful without allowing it to change records. It might prepare a sourced status summary, identify missing documents or draft a review note. Read-only access does not remove confidentiality risks, but it lets the team evaluate information quality separately from the responsibility of changing business data. Remove fields the task does not need before testing the connection. Credentials and connection secrets should stay out of documents or explanatory text that the model can read. OWASP's sensitive-information guidance highlights the need to protect such data. Generated text should remain an output to review, not become an instruction that grants the application additional access.
Make evidence usable rather than decorative
A source label is a beginning, but the reviewer also needs a clear route to verification. Show the relevant passage, record identifier or filters used in a calculation. Separate retrieved information from the conclusion drawn from it. A correct amount can still mislead if its company, period and currency are missing. Where sources disagree, describe the conflict rather than merging them into a single confident answer. A link alone does not prove that a document supports the interpretation. Help the reader inspect the relevant evidence, understand an excluded record and narrow the question when the available information is insufficient for a reliable conclusion.
Give the connection an operating owner
Someone needs to own the connection after the demonstration. New document versions, deleted records, role changes and altered fields can all affect its behaviour. Decide who watches for those changes, where failures are reported and when the connection should be paused. Agree which operational information is recorded and how long it remains available; troubleshooting does not automatically require keeping complete document contents indefinitely. Include stale sources, revoked access, contradictory records and unanswerable questions in acceptance testing. Keep the outcomes in a short review record. The result should explain how access is granted, how it is withdrawn and how the connection can be retired without leaving forgotten copies behind.
- Source owner and access approver are identified.
- Freshness limits and failure behaviour are defined.
- Revoked access and deleted records have been tested.
