Postgres Retrieval Guardrails: Controlling Financial Research Dashboard Query Limits

Short answer: a financial research dashboard retrieval architecture should put a budget gate before search, bound candidate and context growth separately, and expose every rejected or truncated query as an observable product event.

A financial research dashboard should never let a broad request silently decide its own cost. The retrieval-augmented generation pattern joins a model with retrieved external documents; that makes retrieval policy part of the answer path, not a background database concern. For research teams, the useful unit is a bounded evidence request: a known scope, a known candidate ceiling, a known context ceiling, and an explicit response when any ceiling is reached.

The index still matters. But index cost at scale is controlled upstream by deciding what deserves indexing, while query cost is controlled at runtime by deciding how much of that index one request may explore. Mixing those decisions produces an expensive system that is hard to explain.

How should a financial research dashboard enforce retrieval query limits?

Use two layers. The first is a request policy gate that checks scope before touching the index: tenant, document collection, date range, requested result count, and allowed retrieval mode. The second is an execution budget that stops candidate generation and context assembly at independently configured ceilings. A request can pass validation and still exhaust its execution budget, so those outcomes need different status codes and different metrics.

Keep the contract boring. A broad query should return a stable client error with machine-readable details, such as QUERY_SCOPE_TOO_BROAD, rather than quietly clipping a ten-year request to one year. A query that is valid but reaches its candidate ceiling should return the available evidence plus limit metadata. The UI can then say “showing results within the current retrieval budget” and offer a narrower date or document filter. Silent truncation is worse: an analyst may read absence as evidence.

The exact limits are workload decisions. I'm not sure there is a defensible universal number, because corpus shape, document length, filter selectivity, and the acceptable interaction time all vary. Resolve that uncertainty with distributions from your own traces, then publish the chosen limits as an API contract. Don't bury them in a database timeout.

This separation also gives the team clean ownership. Product defines acceptable scope. Search engineering owns candidate work. The generation layer owns context assembly. Operations watches the full path — request, retrieval, context, response — without treating every limit event as an outage.

Before and after: from open search to a cost envelope

Picture the unbounded version in words. A user enters “energy sector risk.” The service searches every permitted research document, produces an unspecified candidate set, reranks it, stuffs as much text as possible into a prompt, and eventually renders an answer. Each stage inherits the previous stage's uncertainty. Adding more documents to the index changes cost even when user behavior does not change.

Now draw the bounded version: request -> scope gate -> candidate budget -> rerank budget -> context budget -> answer with evidence and limit metadata. The arrows matter. The system rejects an invalid scope before retrieval, and it records where a valid request spent its allowance. Growth in the corpus no longer grants a single request permission to do proportionally more work.

That's the shift.

Index cost needs its own envelope. Treat raw documents, searchable chunks, and retained versions as three different populations. A quarterly filing and a one-paragraph analyst note should not acquire identical chunking merely because one pipeline handles both. Define inclusion rules before ingestion, preserve document identity and source metadata, and make re-indexing an explicit operation. If a parser or chunking rule changes, version the resulting records so an old and new index are not accidentally queried as one logical corpus. Those are architectural controls, not benchmark claims; their values depend on the dashboard's source mix.

For query execution, record counts at every narrowing point: eligible documents after filters, candidates read, candidates reranked, evidence items selected, and context units admitted. A single “search duration” histogram can't tell you whether a broad date filter, weak metadata, or context assembly caused the jump. Counts make the before/after crisp. They also let an engineer test a policy change against captured request shapes without asserting that a single fixed top-k works for every research question.

There is a trade-off. Hard ceilings make cost and tail behavior easier to control, but they can reduce recall for genuinely broad research. This design is not suitable when the product promise is exhaustive discovery across an arbitrarily large corpus in one interaction. In that case, use an asynchronous research job with progress, pagination, and a durable result set instead of pretending an interactive query has no boundary.

A copyable TypeScript policy gate

The following policy is deliberately local and explicit. Its numbers are illustrative configuration values, not universal recommendations. The important mechanism is that validation, execution consumption, and response metadata share one typed vocabulary.

type RetrievalRequest = {
  tenantId: string;
  query: string;
  collectionIds: string[];
  fromDate: string;
  toDate: string;
  requestedResults: number;
};

type RetrievalPolicy = {
  maxCollections: number;
  maxDateRangeDays: number;
  maxRequestedResults: number;
  maxCandidates: number;
  maxContextUnits: number;
};

type LimitCode =
  | "TOO_MANY_COLLECTIONS"
  | "DATE_RANGE_TOO_WIDE"
  | "TOO_MANY_RESULTS";

type PolicyDecision =
  | { allowed: true; candidateBudget: number; contextBudget: number }
  | { allowed: false; status: 422; code: LimitCode; allowedMaximum: number };

const daysBetween = (fromDate: string, toDate: string): number => {
  const milliseconds = Date.parse(toDate) - Date.parse(fromDate);
  return Math.ceil(milliseconds / 86_400_000);
};

const applyRetrievalPolicy = (
  request: RetrievalRequest,
  policy: RetrievalPolicy,
): PolicyDecision => {
  if (request.collectionIds.length > policy.maxCollections) {
    return {
      allowed: false,
      status: 422,
      code: "TOO_MANY_COLLECTIONS",
      allowedMaximum: policy.maxCollections,
    };
  }

  if (daysBetween(request.fromDate, request.toDate) > policy.maxDateRangeDays) {
    return {
      allowed: false,
      status: 422,
      code: "DATE_RANGE_TOO_WIDE",
      allowedMaximum: policy.maxDateRangeDays,
    };
  }

  if (request.requestedResults > policy.maxRequestedResults) {
    return {
      allowed: false,
      status: 422,
      code: "TOO_MANY_RESULTS",
      allowedMaximum: policy.maxRequestedResults,
    };
  }

  return {
    allowed: true,
    candidateBudget: policy.maxCandidates,
    contextBudget: policy.maxContextUnits,
  };
};

const policy: RetrievalPolicy = {
  maxCollections: 8,
  maxDateRangeDays: 366,
  maxRequestedResults: 50,
  maxCandidates: 200,
  maxContextUnits: 24,
};

Return the decision before opening a Postgres transaction. If it is allowed, pass only the two execution budgets to the retrieval component; do not let that component infer permission from requestedResults. Candidate count and result count represent different work. A request for ten displayed results might inspect more candidates, but it must still stop at the declared candidate budget.

Then attach limit state to the normal response. A small object such as { candidateBudget, candidatesRead, contextBudget, contextUnitsUsed, limited } is enough for the UI and telemetry to agree about what happened. Avoid a boolean alone. Engineers need to know which boundary was approached, and analysts need to know whether the evidence set was constrained.

Can strict limits hide evidence or punish complex questions?

Yes. A limit can protect the service and still be wrong for the user. The fix is not an invisible larger number; it is a second interaction mode with a different contract.

Keep the interactive path for questions that fit a bounded scope. When the scope gate rejects a request, preserve the user's query and suggest concrete refinements based on the rejected field: shorten the date range, choose fewer collections, or request fewer displayed items. For research that must cover all filings in a long period, switch to a job model that can partition work, expose progress, and retain the assembled evidence. The user should choose that mode knowingly because its latency and resource profile are different.

Don't retry a 422 policy rejection. Nothing transient happened. A client may retry a capacity response according to the server's guidance, but repeated automatic retries of an invalid scope only amplify load and muddy alerting. This distinction is easy to test: validation errors should increment a product-facing rejection counter, while capacity responses belong in service saturation telemetry.

The other objection is recall. Retrieval-augmented generation was introduced as a way to combine generation with retrieved external knowledge, but the research paper does not prescribe one operational limit for every application. That leaves teams responsible for evaluating whether their own candidate and context ceilings preserve acceptable evidence coverage. Use a labeled set of financial research questions, include narrow and broad scopes, and compare evidence retrieval before and after each limit change. If broad questions degrade, route them to the asynchronous mode or improve filtering and chunk selection before increasing every budget.

One caveat: a dashboard that must guarantee exhaustive regulatory review should not represent bounded semantic retrieval as completeness. Stick with a review workflow that tracks the full required document set and completion state; semantic retrieval can assist navigation, but its top results are not a coverage ledger.

What should teams observe before changing the limits?

Start with four dimensions: scope rejection rate, candidates read per accepted request, context utilization, and end-to-end latency. Break them down by collection class and date-range bucket, not by raw query text. Raw financial queries may contain sensitive research intent, and logging them is rarely necessary for tuning a numerical boundary.

Alerts should describe broken service behavior, not expected policy enforcement. A sudden rise in DATE_RANGE_TOO_WIDE after a UI release is a product signal. Candidate utilization pinned near its ceiling alongside falling evidence coverage is a retrieval-quality signal. Capacity responses and latency are operational signals. Put them on different charts. Page on the condition that requires immediate service action; send policy and quality trends to the teams that can change the interface, index, or evaluation set.

Test changes as paired before/after experiments on the same approved request set. Record the policy version with each trace, deploy one change at a time, and compare both resource counters and evidence coverage. Raising maxCandidates without watching context utilization may buy no visible improvement. Raising the context budget without checking evidence selection may just admit redundant chunks. The useful question is not “did the request get faster?” It is “did this policy produce adequate attributable evidence inside the declared envelope?”

Limits are part of the product contract.

References

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: https://arxiv.org/abs/2005.11401