Enterprise: Security and Data Handling

What happens to a record when it passes through the review call

This page summarizes the current Review Engine data flow for security review: what is transmitted, what JRS does not persist, what derived telemetry may be retained, and what the interface does not claim. Implementation and contract details remain subject to the versioned API materials and current production controls.

Make a technical integration inquiry → API contract and integration schema → OpenAPI 3.1 specification

The short version

What a reviewer usually needs in one paragraph

Record text is sent over TLS to this endpoint and from there to Anthropic, the model provider, which is a third party. Your record text is not written to any table, not echoed back in the response, and not logged. What the model writes about the record on the versioned route is stored: a short note against each of the five conditions, and a suggested rewritten version of the passage. That is model output about your record rather than the record. It is kept for 90 days and then removed. The evaluation record itself is kept: the date, the five condition statuses, the routing outcome, the run count, the consistency figure and the engine version. The raw record text you submitted is never stored at all by JRS. There is therefore a store, and the retention and residency questions are real ones for your organisation to answer rather than ones we can answer for you.

Data handling, field by field

What you send	What happens to it	Retained
`text`: the full text of one record	Held in memory for one request, evaluated, discarded when the response is written. Truncated to 8,000 characters before evaluation.	No
`runs`: 1 to 5	Controls how many independent evaluations run. Recorded as a count only.	Count only
Bearer token	Compared against the per-organisation allow list. Identifies the partner, never the individual.	Not stored with the record
Result of the evaluation	Per-condition statuses, the routing determination and the consistency figure are kept as telemetry so the programme can report reproducibility. So is a short note against each condition, which the model is instructed to ground in the record text, and a suggested rewritten version of the passage.	Statuses, figures, and model-written text about the record

The distinction that matters to a reviewer: your record is not stored, but text the model wrote about your record is. A stored row is not designed to reproduce your record, and no row holds it. But nothing in the implementation prevents a suggested rewrite from retaining phrasing from the passage it rewrites: the only controls are an instruction to the model and a 600-character limit. There is no verbatim check. Treat that as retained record-derived content when you assess this endpoint, not as metadata.

Authentication

The endpoint is fail-closed. No token means no access, and no evaluation is performed. Tokens are issued per organisation, so one can be rotated or revoked without affecting any other partner.

Authorization: Bearer <your-token>
Content-Type: application/json

A missing or unrecognised token returns 401 and names no environment variable, no internal hostname and no configuration detail in the public error body.

Model provider and key custody

The evaluation is performed by a hosted model provided by Anthropic, which receives the record text. The provider API key exists only as a server-side environment variable and is read only inside the edge function. It never appears in any page, any client bundle, any response body, or any committed file. No browser ever holds it, and no partner is ever issued it: partners receive a JRS token, which is a different credential with a different scope and its own revocation path.

Submitted text is not used for model training.

Availability controls

Control	Value	Note
Rate limit	20 requests per 60 seconds, per IP	Best-effort and per-instance. Edge isolates do not share state, so treat it as a guard rail rather than a quota.
Maximum record length	8,000 characters	Longer input is truncated before evaluation, not rejected.
Minimum record length	40 characters	Shorter input returns `400 record_too_short`.
Runs per request	1 to 5	Above 1 returns a variance block disclosing the spread.
Transport	TLS only	Served from the edge.

Audit correlation

Every response carries a request_id, returned in the body and in the X-Request-Id header. It is the join key between your audit trail and ours. It is an identifier, not a copy of the record, so correlating an event costs you nothing in exposure.

What this does not claim

Read this before mapping it to a control

JRS is not a certification, an accreditation, or an audit opinion, and it does not establish compliance with ISO/IEC 42001, the NIST AI RMF, the EU AI Act, or any other framework. The engine is unvalidated and single-model, in operational validation. Reproducibility is disclosed rather than hidden, and reproducibility is not accuracy and not validation. No effectiveness claim is made. Every API response repeats this in its own payload, so a reviewer reading a raw response sees the same disclosure that appears here.

A security review of this endpoint is a review of data handling. It is not, and should not be presented internally as, evidence that the determinations are correct.

Questions a reviewer can send directly

Scope, token issuance, rotation cadence, subprocessor detail and contractual terms are handled in writing. Submissions route to a private operational dashboard, not to a public queue and not to a mailing list.

Send a security question → Privacy policy Terms