Decision Reconstruction Manifest
The Manifest is a portable, machine-readable evidence artifact describing one JRS evaluation. It records what was evaluated, which versions and vocabularies governed the evaluation, what the engine returned, whether human review remains required, and how the artifact can be checked later.
include_manifest: true. Default responses omit it. The artifact is unsigned, can contain record-derived notes, and is not automatically stored in a customer-controlled evidence repository. The Engine remains unvalidated.What the Manifest does
Pins the evaluation
Records the JRS, Codebook, engine, model, API, and Manifest versions used for the evaluation.
Preserves the result
Carries the five condition results, routing vocabulary, warnings, and human-review requirement in a portable structure.
Supports later verification
Uses an input hash and a canonical Manifest hash so later reviewers can check correspondence and detect alteration.
Leaves storage with the customer
The target architecture returns the artifact to the customer for retention in its own evidence store. JRS is not intended to become the permanent repository for customer records.
Current implementation and target architecture
| Element | Current state | Target licensing state |
|---|---|---|
| Review Engine response | Returns a request identifier, version metadata, five engine-key condition results, routing determination, optional variance, and an optional authenticated Manifest. | Returns the API result and a conforming Manifest, or provides a documented transformation that produces one. |
| Manifest generator | Controlled implementation library with schema validation, canonicalization, hashing, refusal tests, and frozen fixtures. | Versioned release component governed by the public schema and the executed integration agreement. |
| Record handling | The current engine receives record text for inference. Raw text is not persisted by JRS. Defined record-derived output is retained as disclosed in the Privacy Policy. | Minimum necessary representation, documented processors, bounded persistence, and customer-approved data flow. |
| Evidence storage | JRS retains defined evaluation telemetry. The public API does not create a customer-controlled immutable evidence repository. | The customer stores the returned Manifest with its own record and retention controls. |
| Signature | Manifest hashing is implemented. Signing is optional and not presently represented as deployed. | Signing, key custody, and verification procedures are agreed where the transaction requires authentication. |
Minimum field groups
| Group | Purpose |
|---|---|
manifest_id, created_at | Identifies the artifact and creation time. |
manifest_version, jrs_version, codebook_version | Keeps the artifact, methodology, and rule versions distinct. |
engine | Records the engine build, model, and API version. |
input | Records the input hash, algorithm, length, and truncation state without requiring the underlying record to be embedded. |
condition_vocabulary, conditions | Declares which condition-key vocabulary is used and records all five results. |
routing | Records both the routing value and the vocabulary used to interpret it. |
human_review | States that human review is required and gives the reason. |
content_class | Declares whether the artifact contains no record content, derived record content, or the record itself. |
integrity | Records the canonicalization method, Manifest hash, and optional signature metadata. |
Integrity and hashing
The input hash allows a holder of the original record to test whether it corresponds to the evaluated input. The Manifest hash is computed over the canonical form of the artifact, excluding the integrity object itself. A changed routing result, version, condition, or input hash therefore changes the Manifest hash.
Human review requirement
Version 1.0 requires human_review.required. The present engine is not established as validated for autonomous consequential-decision use. A Manifest records a documentation evaluation. It does not decide whether the underlying decision is correct, lawful, compliant, or professionally justified.
Customer-controlled storage model
The intended integration places the customer record and long-term evidence store under customer control. The platform sends an approved representation for evaluation, receives the result and Manifest, and stores the Manifest beside its own decision artifact. The Manifest does not require JRS to retain the underlying record.
Place in the enterprise pathway
The Manifest is the central technical integration artifact, not the complete commercial asset. A qualified platform can first examine the public schema, then evaluate the current Review Engine and its documented relationship to the Manifest. Integration evidence may support a later licence, an exclusive licence, or acquisition of a defined asset package.
Evaluate
Test the current API, schema relationship, integrity controls, data handling, workflow fit, and limitations under a bounded scope.
Integrate
Map the result and Manifest to the platform's records, evidence store, review queue, and human-routing controls.
License or acquire
Define only the methodology, implementation, brand, derivative, support, exclusivity, or transfer rights actually established and granted.
Limitations
No legal conclusion
The Manifest does not establish admissibility, legal sufficiency, compliance, certification, or defensibility in law.
No autonomous decision
The Manifest preserves a review result. The responsible human or organization retains authority over the consequential decision.
Derived content may remain sensitive
Condition notes and remediation text can paraphrase the evaluated record. The content class must identify that risk.
Vocabulary remains explicit
The schema does not silently relabel Review Engine keys as Codebook conditions. Any mapping must be documented and versioned.
Rights and licensing boundary
Publication of this specification permits inspection of the schema. It does not grant source-code rights, implementation rights, derivative rights, trademark rights, commercial embedding rights, exclusivity, or transfer rights. Any such right must be identified in a separate executed agreement after the relevant rights position has been established.