Evaluate whether JRS fits an existing platform workflow.
The integration route tests the current Review Engine, its documented API response, the separate Manifest v1.0 implementation, data handling, human-routing requirements, and the work required to connect them without treating target architecture as deployed capability. The engine remains unvalidated and in operational validation.
Target integration pattern
Inspectable technical surfaces
Current API
Token-authenticated POST /api/v1/review-engine, documented request and response, request identifiers, error vocabulary, version metadata, and optional repeated-run variance.
Manifest v1.0
Public JSON Schema, constructed example, controlled builder, canonicalization, input and artifact hashing, content classification, refusal controls, and an offline validator.
Data flow
Raw text is transmitted to the model provider for inference and is not persisted by JRS. Defined derived telemetry is retained on the versioned route as disclosed in the Privacy Policy.
Human control
The output identifies documentation conditions. It does not decide whether the underlying decision is correct, lawful, compliant, admissible, or professionally justified.
Current implementation versus evaluation target
| Element | Current implementation | Controlled evaluation question |
|---|---|---|
| Engine response | Versioned structured result using Review Engine condition and routing vocabularies. | Can the platform receive, validate, correlate, and route the response? |
| Manifest delivery | Optional on an authenticated request; not returned by default. No customer-controlled storage is provided. | Can an explicit adapter produce and validate a conforming artifact without silent vocabulary conversion? |
| Evidence storage | Customer-controlled storage is target architecture. | Can the platform retain the Manifest beside its record under its own retention controls? |
| Integrity | Hash consistency is implemented. Digital signing is not deployed. | Can alteration be detected, and what signing or custody controls would the platform require? |
| Security posture | Operational controls and disclosures exist. No broad security certification is claimed. | What due diligence, DPA, SLA, incident, processor, and access requirements apply to the bounded evaluation? |
Evaluation success measures
Contract fidelity
Requests and responses match the published contract, errors fail clearly, versions remain identifiable, and the adapter does not invent or relabel values.
Traceability
The request identifier, input hash, versions, five condition results, routing vocabulary, human-review requirement, and integrity metadata remain reviewable.
Data boundaries
The platform can document what is transmitted, retained, returned, stored by the customer, deleted, or excluded from the test.
Operational independence
A technically competent evaluator can run the documented test and validate the artifact without relying on undocumented founder explanation.
What this route does not establish
A successful technical evaluation does not establish market adoption, organizational effectiveness, legal compliance, accuracy on real records, production scale, service availability, security certification, or that every potential commercial right is available. Those matters require separate evidence and written terms.