Build a governed business application
Follow a supplier-review Case through the published API to see evidence admission, governed inquiry, human authority, and recovery in practice. Its diligence packet contains an unresolved recovery-control exception. Procurement needs a commercial recommendation; Security needs assurance evidence; a designated risk owner must decide whether the company can proceed. The same interface can serve work with different owners, contracts, and consequences.
These paths follow the published Platform API. Use credentials, identifiers, and request bodies from your authorized environment.
Start with a governed Case
Create a Case in the organization’s workspace. Its identifier keeps the review, its evidence, and subsequent executions connected to the same undertaking.
curl --fail-with-body -sS -X POST \
"$INDWEL_API/v1/organisations/$ORG_ID/workspaces/$SPACE_ID/cases" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $CASE_KEY" \
--data-binary @case.json -o case-response.json
jq -r '.resourceId' case-response.jsonresourceId. See the Cases & Governance contract for the request body.Run within the Case
Create a Run Plan in the Case, then submit a Run. Planning and execution are separate operations. An accepted response establishes that execution was requested—not that the review has concluded.
POST …/cases/{caseId}/run-plansPOST …/cases/{caseId}/runsGET /v1/operations/{operationId}BASE="$INDWEL_API/v1/organisations/$ORG_ID"
BASE="$BASE/workspaces/$SPACE_ID/cases/$CASE_ID"
curl --fail-with-body -sS -X POST "$BASE/run-plans" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $PLAN_KEY" \
--data-binary @plan.json -o plan-response.json
curl --fail-with-body -sS -X POST "$BASE/runs" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $RUN_KEY" \
--data-binary @run.json -o run-response.json
jq '{operationId,resourceId,status,receiptId}' run-response.jsonKnow what happened before proceeding
Read the operation to establish its state. Inspect evidence, policy, integrity, and receipts through the Case-scoped Run projections. After a timeout, inspect the existing operation or Run before retrying.
GET/v1/operations/{operationId}
Run receiptsGET…/runs/{runId}/receipts
EvidenceGET…/runs/{runId}/evidence
IntegrityGET…/runs/{runId}/integrity
Run projections are scoped to the organization, workspace, and Case. Use the API Reference to inspect full paths, authorization, and errors.
Recover without duplicating Work
Preserve the request's idempotency key and known operation identity. Reuse the key only for the same logical mutation. Neither an accepted operation nor a receipt identifier proves that an external action occurred.
Supplier renewal
From analysis to an authorized decision
The analysis is an input to a decision, not the decision itself. The Vendor Risk Review contract specifies the packet custody requirement, the risk-owner's authority, the review → decided transition, and the separately governed vendor.disposition effect.
- AdmitVendor packet and provenance
- InvestigateCase-scoped plan and Run
- RequestRisk-owner participation
- AdvanceGuarded business transition
- InspectEffect outcome and receipts
Record the authorized decision
Once the server identifies the eligible reviewer and the current Case revision, submit a participation for the declared requirement. An expected revision prevents silently approving a superseded review.
POST …/cases/{caseId}/human-authority-requirements/
authority.risk-owner/participations
Idempotency-Key: <stable-decision-key>
{
"expectedRevision": 7,
"disposition": "approved"
}Request the business transition
The Platform—not the client—determines whether evidence and human authority jointly satisfy record-disposition. Read the current Case revision before submitting the transition.
POST …/cases/{caseId}/business-transitions/
record-disposition
Idempotency-Key: <stable-transition-key>
{
"expectedRevision": 8
}If a request times out, inspect the operation, Case stage, and receipts before retrying with the same idempotency key. The decision and any resulting external action have separate evidence requirements.Follow the supplier review through completion
The Platform enforces institutional authority
In an ordinary company, corporate leadership may establish risk limits while Procurement owns commercial criteria, Security owns assurance standards, and a supplier-review team owns its examination. Each office can contribute its own Cognitive Contract within its delegated jurisdiction. The Work Mandate states the purpose and completion criteria of the actual renewal. An institution with branches, committees, or clinical services may distribute the same concerns differently. The application follows those responsibilities rather than imposing an organizational chart. The client authenticates an existing principal, addresses an authorized workspace and installed App Version, submits valid inputs, and inspects the resulting governance and receipts. It never grants itself authority by composing a request.
The supplier packet may be admissible for one review but restricted for another. The company’s exposure limits, the independent standards of Procurement and Security, the team’s review duties, and this Work Mandate must all remain traceable when a Run is planned. The installed application supplies review and disposition states; it does not erase those separate obligations.
The explicit workflow contract determines evidence and human requirements for a transition, not a fixed path of reasoning. A held transition can coexist with continuing inquiry. Broader institutional scope resolution is a separate governed concern.
Explore the API
Consult the published request and response models, or learn how business applications use these governed operations.