ClairaClaira Help Desk

Access Request Screening

See in English

Use Claira to screen documents for responsiveness to an access-to-information, ATIP, or FOI request, applying a defined request scope consistently across the collection.

Access Request Screening

Access-to-information, ATIP, and FOI requests are all variations on the same problem: a requester defines a scope, and the public body has to find every record that falls inside it -- no more, no less. Get the scope too wide and you over-disclose, miss the deadline, or both. Get it too narrow and you risk a complaint and a re-do. The work itself is unglamorous: a coordinator (or a small team) reads thousands of records against a single paragraph of scope language.

Claira takes that paragraph, applies it consistently to every document in the collection, and returns a responsiveness call backed by the excerpts that drove it. Reviewers stay in the loop on the partials and the close calls -- which is where the judgment actually matters.

How Claira helps

  • Applies the scope consistently. The same request scope is read against every document, eliminating the drift that creeps in when several reviewers interpret the language differently over a long review.
  • Returns a structured call. Each document is tagged Responsive, Partially Responsive, or Not Responsive, with the scope element that matched and a short justification.
  • Surfaces the partials. Mixed-content documents -- where some passages fall inside the scope and others do not -- are flagged for the redaction and exemption pass that comes next.
  • Grounds every call in excerpts. The supporting text is quoted directly so the access coordinator can verify the call without re-reading the document end-to-end.

When to use this

  • First-pass responsiveness review on a freshly assembled records collection
  • Validating reviewer responsiveness calls before the file is finalised
  • Triaging the gray-zone partial matches that need a coordinator's judgment
  • Preparing a clean responsive set as the input for exemption review

A hypothetical request

The sample prompt below is built around a worked example so you can see what a useful scope statement looks like. Adapt it to your actual matter.

Hypothetical organisation. Regional Transit Authority (RTA) -- a public transit body responsible for bus, light rail, and paratransit service across a metropolitan area.

Hypothetical request.

"All records concerning the decision to discontinue Route 47 bus service, dated between January 1, 2024 and the date of this request, including internal emails and meeting records, ridership and financial analyses, communications with the regional or municipal authority, and consultation records with affected community groups, employee unions, or accessibility advocates."

The request is narrow enough to be tractable but broad enough that responsiveness calls require judgment: a board agenda that lists Route 47 alongside thirty other routes is not substantively about the discontinuation decision; a single sentence inside a long operations report might be. That ambiguity is exactly what the prompt has to handle.

Sample prompt

Access Request Screening Prompt

Determine whether this document is responsive to the following access request.

REQUEST SCOPE: All records concerning the decision to discontinue Route 47 bus service, dated between January 1, 2024 and the date of this request, including:

  • Internal emails and meeting records
  • Ridership and financial analyses
  • Communications with the regional or municipal authority
  • Consultation records with affected community groups, employee unions, or accessibility advocates

Apply these rules:

  • A document is RESPONSIVE only if it substantively addresses the Route 47 discontinuation decision. A passing mention of Route 47 in a list (e.g., a system-wide schedule or a generic board agenda) is not responsive on its own.
  • A document is PARTIALLY RESPONSIVE if some passages fall inside the scope and others clearly do not -- typical of mixed-topic email threads, all-staff updates, or operations reports.
  • A document is NOT RESPONSIVE if it falls outside the scope, including documents about other routes, unrelated capital projects, or general budgeting that does not reach the discontinuation decision.
  • Date the document by its sent or signed date; if the date is missing or unclear, note that in the justification.
  • Do not assess statutory exemptions (personal information, advice and recommendations, solicitor-client privilege, third-party information, etc.). Those are a separate downstream step.

Report:

  • Responsiveness Call: Responsive / Partially Responsive / Not Responsive
  • Scope Elements Matched: list which bullet(s) of the request scope this document falls under (or "none")
  • Justification: 1-2 sentences explaining the call, including the subtext or context you relied on
  • Supporting Excerpts: short quoted passages from the document

This prompt is structured to be lifted into any access regime -- ATIP, federal or provincial FOI, FOIA, or an equivalent statute. Replace the request scope with your actual request language and keep the rest of the structure intact.

Tips for better results

Paste the requester's exact wording into the REQUEST SCOPE block, then add a short interpretation note underneath if your access coordinator has clarified ambiguous language with the requester. Do not paraphrase the request itself -- the precise wording is what governs responsiveness.
  • Anchor the scope with concrete examples of what is out. The sample prompt explicitly excludes other routes, unrelated capital projects, and general budgeting. Negative examples cut the false-positive rate more than any positive guidance.
  • Use Case Context for organisational shorthand. Internal acronyms, route codes, project names, committee names, and the names of relevant decision-makers all help Claira recognise responsive content that does not contain the obvious keywords.
  • Treat Partially Responsive as the working bucket. That is where the redaction, severance, and exemption work lives. Filter to it after the bulk scan and feed it into the next stage of review.
  • Run exemption review as a separate workflow. Personal-information, advice-and-recommendations, and privileged content are exemption questions, not responsiveness questions. Mixing them produces muddy calls. Use Privilege Review and PII Identification as follow-on passes on the responsive set.
  • Pressure-test the prompt on edge cases first. Pick five documents you already know the answer for -- ideally one obvious responsive, one obvious not-responsive, and three close calls -- and run the prompt on those before scaling. If the close calls do not come out the way your coordinator would call them, the scope language needs sharpening.
Claira's responsiveness screen is an AI-assisted triage layer, not a final access decision. The access coordinator remains responsible for the responsiveness determination, the exemption analysis, and the disclosure package. Treat Claira's output the way you would treat a junior analyst's first pass: useful, fast, and always confirmed before release.

Need help? Contact support@claira.to

Cette page vous a aide?

Continue reading