JRS Review Engine API

JRS, the Justification Review Standard, is the methodology. It is the review logic and the documentation review standard: a set of conditions applied to a record, inside whatever workflow an organisation already runs.

The JRS Review Engine is a technical implementation of that logic. It applies a documented technical mapping of the conditions to one record and returns a structured determination. The standard is usable without the engine. The mapping remains under methodological review and is not represented as exact or identical to the Codebook vocabulary.

What it does

You send the text of one record. The engine reads it against the five conditions: reconstructability, basis identification, chronological integrity, decision-process traceability and evidentiary sufficiency. It returns a structured result describing which conditions the record meets and where its reasoning cannot be reconstructed.

Ask for more than one run and the spread is returned to you. Set runs above 1 and the response carries a variance block showing how far the runs disagreed. A single-model engine that hides its own instability is worth less than one that reports it.

Endpoint

POST https://www.jrsstandard.com/api/v1/review-engine

The unversioned route /api/review-engine is the same implementation. Build against the versioned path.

One call, start to finish:

curl -X POST https://www.jrsstandard.com/api/v1/review-engine \
  -H "Authorization: Bearer $JRS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Following review of the incident report and the two witness statements dated 11 March, the decision was to issue a final written warning.",
    "runs": 1
  }'

What happens to the text you send. It is transmitted 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 our database. What the model writes about your record on this versioned route is kept as programme telemetry: a short note against each of the five conditions, and a suggested rewritten version of the passage. Deciding whether that transmission and that retention are acceptable for a given record is your organisation's call, and you should make it before you send anything.

Run one now, without a token

Paste a record and run it. No account, no token, no contact. The sandbox is capped at three records per day per address and truncates at 2,000 characters. Nothing you paste here is stored: the sandbox writes no database row at all, which is a stronger guarantee than the versioned route, where the per-condition statuses, a short note against each condition and a suggested rewrite of the passage are kept as programme telemetry.

Redact before you paste. Use a record you are comfortable sending to a third-party model, or the sample below.

Authentication

Send your token as a bearer credential:

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

The endpoint is fail-closed. No token means no access. Tokens are issued per organisation, so one can be rotated or revoked without affecting anyone else. To request one, use the enterprise inquiry form.

Request

{
  "text": "The full text of one record.",
  "runs": 1,
  "include_manifest": false
}

Response

Current-state boundary. The default response is shown below. An authenticated request with include_manifest: true adds a development Manifest that follows the public Manifest v1.0 package. It has a self-consistency hash, not a signature or a customer-controlled evidence store. The Engine remains unvalidated.

{
  "request_id": "f90a631d-8a7c-40c6-8f89-56dc31fbd786",
  "api_version": "v1",
  "engine": "JRS Review Engine",
  "engine_version": "0.1.0-validation",
  "model": "claude-haiku-4-5-20251001",
  "evidence_stage": "operational_validation",
  "disclaimer": "Unvalidated engine in development. Output is from a single model; reproducibility is disclosed, not hidden, and is distinct from accuracy and from validation. No effectiveness claim is made.",
  "reviewed_at": "2026-08-25T12:00:00.000Z",
  "runs": 1,
  "result": {
    "conditions": {
      "basis_identification": {"status":"review","note":"The stated basis is not linked to an identified source in the record."},
      "reasoning_traceability": {"status":"review","note":"The path from evidence to conclusion is incomplete."},
      "cold_reviewer_clarity": {"status":"review","note":"A later reviewer would require additional context."},
      "accountability_support": {"status":"review","note":"The available record does not identify sufficient support for the conclusion."},
      "temporal_reconstructability": {"status":"pass","note":"The dated sequence can be followed from the record."}
    },
    "determination": "review_required",
    "remediation_note": "Identify the source material and preserve the reasoning connecting it to the conclusion.",
    "finding": {
      "ai_function": "analysis",
      "condition_triggered": "basis_identification, reasoning_traceability, accountability_support",
      "determination": "review_required",
      "compliant_version": "A revised passage would identify the source, chronology, and reasoning used."
    }
  }
}

When runs is above 1, a variance object is added alongside result.

Audit correlation

Every response carries a request_id in the body and the same value in the X-Request-Id header. Record it beside whatever your own system writes when the record is reviewed.

This is the feature that matters in a regulated function. When someone asks months later how a particular record came to be assessed the way it was, the identifier is what connects your entry to this call. Without it, an external service in the middle of a documented process is a gap in the very thing the process is meant to establish.

Errors

Every error response carries a request_id as well, so a failed call can be reported and traced.

Rate limit

20 requests per 60 seconds, per IP. The limit is enforced per running instance and is described here exactly as it is implemented: best effort. It is not backed by a shared store, so under horizontal scaling the effective ceiling can be higher than the stated one. Treat it as a guard against runaway loops, not as a quota you can rely on. A firm quota is part of a licence, not of this limiter.

Governance reporting, and exactly what it does not mean

With that boundary stated, the practical use is straightforward. A record-level review produces a per-record finding about whether a decision can be reconstructed from its own record, and an aggregate rate across a population. Organisations running an AI management system generally need evidence of two things this speaks to: that AI-assisted outputs are subject to human review with a documented basis, and that the resulting records remain traceable after the fact.

Decision Reconstruction Risk is the condition a record is in when it cannot independently show why a consequential decision was reached. It is a documentation property, measured from the record. It is not a legal conclusion, a compliance status, or a statement about whether the underlying decision was correct.

There is no separate governance-reporting endpoint today. Aggregate reporting is produced from the results you already receive, and per-record results are yours to retain. Nothing on this page describes a route that does not exist.

Data handling

Record text is sent to the engine, assessed, and used to produce the response. Send de-identified text. If your records contain personal data, privileged material, or anything you would not want leaving your environment, remove it before the call. De-identification is agreed in writing before any engagement that involves real records.

For a bounded organizational evaluation, the Organization Mini-Pilot summarizes routing and condition patterns across a small record set. Raw record text is not persisted by JRS, but the text is still transmitted for model inference. Use de-identified or non-sensitive text unless your organization has approved that data flow.

Getting a token

Send your organisation, intended record type, environment, and expected volume through the enterprise inquiry form. Qualified integration requests are reviewed before any production token or commercial access is issued. Scope, access terms, and any fees are documented before use.