Skip to Business App Engine
Developers

Business App Engine

Build business applications on Indwel

Business App Engine gives institutional Work a durable application boundary. The institution defines the purpose, distributes decision rights, and determines what completion means. Developers version the data, workflow, and permitted transitions; Indwel resolves the applicable Cognitive Contracts, governs execution and evidence, and records what actually occurred. No single reference application or organizational structure determines the model.

Illustrative uses Policy questions, supplier reviews, and operational releases—not prescribed application types.

Illustrative HTTP request Business App Engine
POST https://api.indwel.ai/v1/organisations/acme/projects/risk/apps
Requestapplication/json
{
  "name": "Case Review",
  "slug": "case-review",
  "description": "Institution-defined review workflow."
}
201 Createdapplication/json
{
  "operationId": "op_20260922_001",
  "resourceId": "app_case_review",
  "status": "accepted",
  "receiptId": "rcpt_20260922_001"
}
Illustrative application creation—not a ready-made workflow. The response identifies an accepted operation; it does not establish a published version, authority to execute, or a completed business outcome.

Application model

Application boundary

An App Definition is the durable domain contract for one application: its schemas, workflow states, admissible actions, and business policy. It can move on its own release cadence without moving identity, evidence custody, or execution into application code.

The App Definition carries domain semantics. Indwel supplies execution authority, evidence custody, receipts, and Settlement.

The illustrated request names a proposed application; acceptance does not define or publish its workflow. Developers subsequently supply schemas, transitions, and application obligations. At execution, Indwel resolves the effective Cognitive Contract, admits evidence, governs Runs, and preserves receipts. Verification of any external effect remains distinct from request acceptance.

Business App Engine does not replace systems of record. A Case stores the durable state needed to move the matter forward and references evidence or external records where they already live.

Release model

Application releases

Draft definitions remain editable until publication. Publishing creates an immutable App Version. A Deployment selects the version for an environment; an Installation binds it to an authorized workspace. Existing Cases retain their original version attribution.

Run Cognitive Unit Tests before publication to verify evidence requirements, authorization, workflow transitions, and Effects.

Create versionPOST…/apps/{appId}/versions
ValidatePOST…/versions/{versionId}:validate
PublishPOST…/versions/{versionId}:publish
DeployPOST…/apps/{appId}/deployments
InstallPOST…/deployments/{deploymentId}:install

Runtime

Cases and Runs

A Case is the durable business matter. It carries the application state that must survive beyond any single execution: participants, evidence references, review state, deadlines, decisions, and the App Version that governs the matter.

One Case can outlive many Runs.

A Case can admit further evidence, pause for review, resume, and be reconsidered when circumstances or policy change. Those Runs do not overwrite the Case. Each remains attributable to the App Version, effective Cognitive Contract, admitted evidence, and authority governing that attempt.

Before execution, Indwel materializes a Run Plan: the declared requirements, evidence posture, authority, and permitted capabilities for that attempt. The resulting Run becomes the durable execution record for inference, decisions, Effects, receipts, and Settlement. Developers can inspect later executions without reconstructing prior state from logs.

One application, governed throughout

A useful business application begins with a real undertaking and an accountable outcome. The institution defines the Work and what completion means; the developer gives that undertaking a versioned application with the data, actions, and transitions it needs. The application serves the institution’s purpose without inheriting its decision-making authority.

Publishing fixes the application version that a workspace installs. Opening a Case then fixes the durable identity of the matter: the evidence considered, people asked to participate, decisions recorded, and changes made across time. One Run can investigate an exception; another can reconsider it after new evidence arrives. Neither Run, by itself, completes the Case or grants permission to perform an external action.

From application version to settled Case
  1. Define the applicationDeveloper

    Set its schemas, workflow, permitted actions, and application Cognitive Contract.

  2. Release the versionPlatform

    Validate, publish, deploy, and install the version in an authorized workspace.

  3. Open the CaseInstitution

    Give the matter a durable identity under the installed application version.

  4. InvestigateIndwel cognition

    Resolve the applicable boundaries, admit evidence, execute a Run, and preserve its basis.

  5. Decide and actEligible people and Governor

    Check evidence and required participation before authorizing a transition or external effect.

  6. Settle and revisitDurable record

    Confirm the observed outcome, preserve receipts, and revisit the same Case if circumstances change.

A Run does not replace a Case. An approved decision does not itself prove an external effect. Settlement requires its own recorded evidence.
Your application defines

Business meaning, workflow states, input schemas, permitted actions, and required human roles.

Indwel governs

Identity and tenancy, resolved contracts, evidence custody, Run execution, transitions, receipts, and continuity.

The institution retains

Ownership of Work, decision authority, external systems of record, and the meaning of completion.

Authority begins with the institution

An institution can delegate different parts of a decision without delegating the decision to its software. A Cognitive Contract sets the applicable bounds of inquiry and action; it does not prescribe what the inquiry must conclude. Those responsibilities may be held by offices that neither report to one another nor share the same workflow.

In a supplier renewal, company policy may set risk limits; Procurement owns commercial criteria, Security the assurance standard, and Finance the spending threshold. The review team examines the evidence, while an eligible risk owner decides the disposition. A Work Mandate gives this particular renewal its purpose and completion criteria.

Procurement and Security may each have independent obligations over the same Case. Indwel resolves the applicable institutional, team, Work, source, and question boundaries without imposing a single reporting chain. A hospital, university, municipality, or cooperative can distribute jurisdiction differently; the institution’s own organisation remains authoritative.

The installed application declares evidence and participation required for a transition. The Case survives interruptions and new evidence; each Run operates under the boundaries resolved for that attempt. Indwel can challenge the expected renewal, but only eligible people may authorize the consequential decision.

One supplier decision · Three distinct responsibilities
InstitutionSet the legitimate terms

Define the purpose, admissible sources, assurance obligations, and who may approve a renewal.

IndwelInvestigate the question

Compare evidence, identify exceptions, test alternatives, and make uncertainty inspectable.

Authorized actorsDecide, act, and verify

Obtain the eligible risk owner's decision, govern the external effect, and check the recorded outcome.

These are separate responsibilities, not a prescribed chain of reasoning. Inquiry can continue while a consequential transition awaits authority.

Credit exceptions, employment-policy questions, and operational releases call for different evidence and decision rights. The Work determines the obligations; API access does not create authority.

At the API boundary, the semantic resolver considers baseline, organization, team, Work, source, and question constraints. The installed application’s indwel.cognitive-contract.v1 declares evidence and human requirements for its business transitions. These published interfaces give effect to particular obligations; they are not a universal editor for every department’s independent contract. Schemas distinguishes these instruments; the Developer Guide follows their consequences through a Case.

Different stakes, different obligations

An answer, a decision, and an external action are not successive grades of application. A single Case may involve all three or only one; its obligations follow the Work and its consequences. The reference applications below show different boundaries without imposing a common workflow.

See how the obligations change

Compare three applications with different governing obligations, then continue to the shared developer contract.

Company Answers

When the answer must be defensible

An employee asks whether an exception to the remote-work policy applies. A plausible answer is not enough. The organization's approved policy—and the employee's right to see it—defines the terms of the inquiry.

The governing boundary

The application declares its answering → answered transition and evidence.company-policy-custody obligation. It cannot create a policy exception simply because a likely answer would satisfy the user.

The inquiry

Indwel can find and compare admitted policy passages, identify ambiguity, or say when the evidence does not support the claim. The Case preserves the answer's basis for reconsideration if the policy changes.

What completes the matter

settle-answer requires the declared evidence basis. The answer artifact, Run, and transition remain inspectable; an accepted request alone is not Settlement.

Developer consequence You build the employee question and response experience; the governed Case, source basis, and accountable answer lifecycle do not have to be improvised in client code.

Vendor Risk Review

When a recommendation must not become an approval

A supplier's risk packet contains an overdue recovery test. Procurement wants commercial terms, Security requires a credible control basis, and a designated risk owner must decide whether exposure is acceptable.

The governing boundary

The installed review workflow requires evidence.vendor-risk-packet-custody and authority.risk-owner. The organization's permissions, Procurement's purpose, and Security's assurance obligation each retain their own jurisdiction.

The inquiry

Indwel may challenge renewal, compare alternative suppliers, and expose weak evidence. It cannot approve its preferred outcome or treat access to one packet as permission to inspect every supplier record.

What completes the matter

An eligible owner records the disposition before record-disposition. A vendor-system change remains a separate governed Effect, requiring an observed receipt rather than an optimistic API success.

Developer consequence The Case holds the evidence, review participation, revision, decision, and effect history without collapsing those distinct acts into a single "approve" button.

Release Readiness

When the consequence occurs outside Indwel

A production release is technically ready, but an unresolved security finding could change the decision. Investigation can improve the release plan; only the properly authorized offices can permit a consequential deployment.

The governing boundary

The workflow requires release and security participation, defined execution rights, and a rollback path. App-defined transitions cannot silently replace the organization's separation of duties.

The inquiry

Indwel can examine the change packet, weigh contradictory test evidence, and propose a safer rollout or a hold. It must not disguise uncertainty as operational permission.

What completes the matter

Human approvals and the permission to execute remain separate. Settlement requires observing the actual deployment state and preserving receipts, including failed attempts and compensating actions.

Developer consequence The application can coordinate analysis and accountable action while keeping production effects, confirmation, and recovery distinct from model output.

These applications carry different obligations, but share the same governed foundation. On smaller screens, use the arrows or swipe between examples.

What carries across applications is Case continuity, evidence custody, contract resolution, bounded execution, and inspectable receipts. The institution—not the example—determines the legitimate outcome.

Human authority

Human review and approval

Business App Engine treats human action as part of the execution record. A Case can stop because evidence is incomplete, separation of duties requires another actor, an exception remains unresolved, or a business condition has not yet matured.

A pause preserves the Case, admitted evidence, prior decisions, and version attribution while work waits. When a reviewer or approver acts, the Platform records the identity, scope, decision, and authority under which that action was taken.

Cognitive Governors evaluate whether the next transition is permitted. Deadlines and recurrences can reopen work without rebuilding control state. Approved Effects and Settlement stay attached to the same durable Work record, so the application does not have to infer authority from application logs after the fact.

Platform API

Business App Engine API

The API family covers authoring, immutable publication, deployment, installation, diagnostics, compatibility, and rollback. Most integrations use a small set of lifecycle calls; the complete operation set remains in API Reference.

Create the applicationPOST …/projects/{projectId}/apps

Publish an immutable versionPOST …/versions/{versionId}:publish

Inspect an installationGET …/installations/{installationId}/diagnostics

Continue with API Reference, Schemas, Artifacts, or the Developer Guide.