Data used to provide IntegriCite

Administrator account information

When an authorised journal administrator signs in with Google or Microsoft, IntegriCite receives the limited profile information made available by that provider, such as a provider account identifier, name and email address. Microsoft sign-in also supplies tenant and directory-object identifiers so that an approved institutional account can be distinguished reliably from another account using the same displayed address. This information is used to authenticate the administrator, check journal access and operate the account.

The identity provider handles the sign-in step under its own privacy terms. IntegriCite does not receive the administrator’s Google or Microsoft password.

Manuscripts and reference data

Uploaded document content is processed to extract and screen references. Uploaded files and full manuscript text are not retained as durable account records. Extracted reference data and working report output are held in temporary job storage so that progress and results can be delivered; that job data expires under the service’s configured time limit. The separate completed-report archive is described below.

When one or more manuscripts are submitted as a queue, each source file is held temporarily in a dedicated private, encrypted Azure staging account until its turn to be screened. Files are processed sequentially and the staged source is deleted immediately after that manuscript reaches a completed or failed state. Recovery copies and blob versioning are disabled for this staging account; an automatic lifecycle rule deletes an orphaned staged file after no more than 48 hours if a worker interruption prevents the normal immediate cleanup.

Small, targeted pieces of reference information may be sent to configured scholarly databases, legal and web-search services, and AI processing providers where needed for a particular screening task. No AI provider is sent the full manuscript.

Where this option is enabled and an administrator requests email delivery, IntegriCite sends the completed reference report and its clearly labelled AI-generated summary to that administrator’s verified account email address using Microsoft’s email services. The recipient is taken from the authenticated journal account rather than entered as an arbitrary address. The email and attached report then form copies in the sending and recipient mail systems outside IntegriCite’s temporary job storage.

If Microsoft Graph does not accept a requested report email, IntegriCite may retain only the already-rendered email and report attachment in private, encrypted Azure recovery storage for up to 48 hours. This allows an administrator to re-send the report without reprocessing the manuscript. The recovery copy is deleted immediately after a successful re-send or by the configured expiry process; the uploaded manuscript is not placed in this recovery store.

For an authorised journal workspace, IntegriCite retains a journal-wide submission-history record containing the uploaded filename, run timestamps and status, aggregate result-category counts, and the AI-generated editorial summary. This summary is generated solely from the screening report and may contain bibliographic names, titles and citation details.

IntegriCite also retains the completed editor reference report and a separate, deliberately neutral author-facing citation-checking draft in private, encrypted Azure report storage. These artifacts contain citation text and bibliographic evidence from the screening report, but not the uploaded manuscript or full manuscript text. Access is provided through the application only after checking that the signed-in account belongs to that journal; public blob links are not used. An authorised journal user may download a copy, after which that copy is governed by the journal's own handling and retention arrangements.

Operational information

IntegriCite retains limited operational records needed for access control, service security, quota management, journal submission history, report access, troubleshooting and delivery. These may include email address, sign-in times, journal membership, uploaded filename, run timestamps and status, aggregate result counts, the report-derived AI summary, private report-artifact identifiers, usage counts, API-token totals, report-email delivery status and cacheable bibliographic entries. Separate technical event and cost records do not include document body text, bibliography text, prompts, model responses or report HTML.

The service operator may receive a short completion notice containing limited operational metadata such as journal, administrator email, a truncated filename, run status, duration, result counts, estimated processing cost and report-email status. It does not include manuscript or citation text. Independent Azure Monitor alerts may also be sent when the application records a run or email-delivery failure, or when a started run has no terminal event within the expected operational window.

Cookies

Necessary session cookies keep administrators signed in and protect the OAuth sign-in flow. IntegriCite does not use advertising or tracking cookies. More detail is available in the cookie policy.

Retention and questions

Uploaded manuscript content and completed job data are temporary. The retention of limited account, cache and operational records follows the configuration needed to provide and support each journal’s service.

Journal submission-history metadata, its report-derived AI summary, and the private completed editor and author-facing report artifacts are retained as shared journal account records for the agreed service period, subject to the journal’s contract and deletion arrangements. Authorised journal users can ask for correction or deletion through the contact below.

If report email is selected, copies retained in the sending mailbox or the recipient’s mailbox are governed by the applicable Microsoft 365 and customer email-retention policies rather than IntegriCite’s temporary job-data expiry. IntegriCite does not control how long a recipient or the recipient’s organisation retains its copy.

A failed-delivery recovery copy is retained for no more than 48 hours at application level, subject to the timing of Azure’s periodic lifecycle deletion process, and is removed sooner following a successful administrative re-send.

A manuscript staged for queued screening is deleted immediately after its screening attempt reaches a terminal state. The separate 48-hour staging lifecycle is a crash-recovery ceiling for orphaned files, not the normal retention period.

For a current retention schedule, a correction to account information or any privacy question, contact lee@automager.co.uk.