Trust Orchestration

Current contract

CheckID API contract V1.2.260123 uses subjects and processes as the primary units. A subject can contain multiple processes; `POST /v1/create/process` creates a process, `PUT /v1/perform/process` executes evidence for that process, and `GET /v1/get/process/detail` returns source-defined status/result context.

No invented state machine

The public source only supports states/results present in the contract examples, such as `PROCESSING`, `ACCEPTED` and process-specific `perform_result`. Public documentation does not present a conceptual lifecycle as an API transition model unless an authoritative transition table exists.

Branching and conditional evidence

Branching must follow process type, purpose, configuration and evidence requirements defined by the implementation. Policy-driven step-up is distinct from technical retry caused by capture or source failure.

Retry, timeout and idempotency

The ZIP does not define a universal retry, timeout or idempotency contract. These behaviors therefore remain contract-specific or Not publicly specified rather than being inferred from common REST practice.

Asynchronous integration

No authoritative webhook delivery contract is present. Retry, ordering, duplicate delivery, replay protection and acknowledgement semantics are therefore marked NOT PUBLICLY SPECIFIED until a primary source is supplied.

Traceability

Orchestration should preserve correlation among subject, process, billcode/transaction reference and result/evidence wherever the contract exposes those identifiers, so a relying party can reconstruct a decision independently of a UI view.